ADO. Оптимизация запросов

[Makc]

На форме есть ListView. В нем находятся 4 колонки. При запуске программы происходит заполнение списка из базы данных:

Код: Выделить всё

Private Sub Form_Load()
   Dim conADO As ADODB.Connection
   Set conADO = New ADODB.Connection
   conADO.ConnectionString = "provider=Microsoft.JET.OLEDB.4.0;" & "data source=" & App.Path & "\db.mdb"
   conADO.Open
   Dim rs As ADODB.Recordset
   Set rs = conADO.Execute("SELECT * FROM table")
   Dim oItem As ListItem
   Do While Not rs.EOF
      Set oItem = ListView.ListItems.Add(, , rs!one)
      oItem.SubItems(1) = rs!two
      oItem.SubItems(2) = rs!three
      oItem.SubItems(3) = rs!four
      rs.MoveNext
   Loop
   rs.Close
   conADO.Close
   Set oItem = Nothing
   Set rs = Nothing
   Set conADO = Nothing
End Sub

При завершении работы происходит сохранение данных:

Код: Выделить всё

Private Sub Form_Unload(Cancel As Integer)
   Set conADO = New ADODB.Connection
   conADO.ConnectionString = "provider=Microsoft.JET.OLEDB.4.0;" & "data source=" & App.Path & "\db.mdb"
   conADO.Open
   conADO.Execute "DELETE FROM [table]", False
   Dim oItem As ListItem
   For Each oItem In ListView.ListItems
      conADO.Execute "INSERT INTO table ([one], [two], [three], [four]) values('" & oItem & "', '" & oItem.SubItems(1) & "', '" & oItem.SubItems(2) & "', '" & oItem.SubItems(3) & "')"
   Next oItem
   conADO.Close
   Set conADO = Nothing
End Sub

Ну так вот, если в списке будет около 10000 записей, тогда чтение займет 8-10 секунд, а сохранение данных - 35-40 секунд...
Как можно оптимизировать процесс чтения и записи, если количество элементов в списке каждый раз меняется?

[Ennor]

Если в промежутке между удалением данных из таблицы и окончанием твоего цикла сохранения программа вылетит или каким-либо еще образом потеряет связь с БД, то ты потеряешь в общем случае непредсказуемое количество данных. По-твоему, это нормально?

Сохранять нужно точечными апдейтами (или инсертами, если новые записи добавляются). Удалять точечными делитами (построчно, да). Ибо когда (заметь, не если, а именно когда) количество записей перевалит за миллион, то твоя архитектура станет неработоспособной. Впрочем, таковой она станет гораздо раньше - уже на ста тысячах.

И это, заметь, я еще ни слова не сказал о принципиальной непригодности такого подхода к многопользовательскому окружению.

Если вкратце - изучай основные концепции в области СУБД. Такое... ну, это что угодно, но только не то, что нужно.

[Andrey Fedorov]

Ну так вот, если в списке будет около 10000 записей, тогда чтение займет 8-10 секунд, а сохранение данных - 35-40 секунд...
Как можно оптимизировать процесс чтения и записи, если количество элементов в списке каждый раз меняется?

Не использовать ListView для таких объемов данных.
Это замедление растет от него.
Возьми любой нормальный Grid, способный работать с Recordset-ом и, при правильном подходе, все резко упростится.

[Makc]

Если в промежутке между удалением данных из таблицы и окончанием твоего цикла сохранения программа вылетит или каким-либо еще образом потеряет связь с БД, то ты потеряешь в общем случае непредсказуемое количество данных. По-твоему, это нормально?

В этом я с тобой полностью согласен! Как-то даже и не подумал, что можно потерять целую кучу информации... спасибо за совет! =))

И это, заметь, я еще ни слова не сказал о принципиальной непригодности такого подхода к многопользовательскому окружению.

Я прекрасно понимаю, что таким образом работать нельзя. И о непригодности этого подхода я знаю. В этом-то как раз и заключается проблема: как выполнить эти операции правильнее?

Не использовать ListView для таких объемов данных.
Это замедление растет от него.
Возьми любой нормальный Grid, способный работать с Recordset-ом и, при правильном подходе, все резко упростится.

Спасибо, попробую!