Архітектура BDE та йогоособливості при роботі з SQL-серверами - все про IT та програмування
Written on 01 Січня 2007 . Posted in Delphi
ЗМІСТ
Кешування дані
Як видно з попереднього розділу, TTable працює з таблицями сервера не якимось хитрим чином, а формуючи нормальні SQL-запити. І тут починається найцікавіше. Виявляється, при виконанні запиту сервер видає записи клієнту (додатку) по черзі та по одному запису. Причому лише "згори донизу". Як тільки записи на сервері скінчилися, сервер повідомляє клієнту про це сигнал EOF замість видачі чергового запису. Звичайно, в деяких сучасних серверах є довільне позиціонування та прохід за вибіркою не тільки зверху вниз, але й у зворотному порядку, але це вимагає від сервера досить великих ресурсів.
Вочевидь, клієнтська частина SQL-сервера може приймати записи від сервера "пачками". Але в будь-якому випадку отримання запису ініціюється лише викликом функції fetch, і за цією командою "вибирається" лише один запис. Тобто. Програма отримує записи по одній незалежно від того, буферизуються вони на сервері/клієнті чи ні.
Оскільки BDE - річ універсальна, він повинен забезпечити можливість переміщення по записам вгору і вниз незалежно від сервера. Тобто. він має забезпечувати кешування записів самостійно. Взяв запис із сервера – поклав у кеш. Це означає, що якщо ви відкрили таблицю в 100 тисяч записів і натиснули в гриді Ctrl-End, то всі 100 тисяч записів "приїдуть" до вас на клієнтський комп'ютер. З таким пожиранням ресурсів треба якось боротися. Якщо TQuery може обмежити кількість вибраних записів умовами запиту, то TTable цього зробити не можна, оскільки як ми вже бачили, TTable формує запити самостійно.