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

Работа VB и СУБД (Access, MSSQL, MySQL, Oracle и пр.)
Правила форума
При создании новой темы не забывайте указывать используемую СУБД.
Makc
Начинающий
Начинающий
 
Сообщения: 18
Зарегистрирован: 03.09.2005 (Сб) 15:42

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

Сообщение Makc » 22.12.2005 (Чт) 23:39

На форме есть 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 секунд...
Как можно оптимизировать процесс чтения и записи, если количество элементов в списке каждый раз меняется?
sitemoney.ru

Ennor
Конструктивный критик
Конструктивный критик
 
Сообщения: 2504
Зарегистрирован: 18.12.2001 (Вт) 3:58
Откуда: Калуга -> Москва

Сообщение Ennor » 23.12.2005 (Пт) 0:48

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

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

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

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

Andrey Fedorov
Член-корреспондент академии VBStreets
Член-корреспондент академии VBStreets
 
Сообщения: 3287
Зарегистрирован: 21.05.2004 (Пт) 9:28
Откуда: Москва

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

Сообщение Andrey Fedorov » 23.12.2005 (Пт) 8:44

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


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

Makc
Начинающий
Начинающий
 
Сообщения: 18
Зарегистрирован: 03.09.2005 (Сб) 15:42

Сообщение Makc » 23.12.2005 (Пт) 15:00

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

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

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

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


Вернуться в Базы данных

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

    TopList