memorytables

← →
oleggar © (2005-11-04 12:42) [0]

возникла проблема .В моем приложении на Delphi несколько query постоянно делают запросы из нескольких dbf по 100000-400000 записей ,и скорость BDE меня не устраивает .Было бы здорово использовать memotables из rxlib ,загрузить туда dbf при старте программы (dbf меняют информацию лишь по ночам ,а запросы делаются днем) и обращаться к memorytables. Как сделать Sql запрос к memorytables и главное ,как закачать туда dbf ?причем иногда структура базы может меняться ,хоть и редко ,хотелось бы ,чтоб автоматически закачивались поля ,если заранее не известен их полный состав.но это не главное .Помогите чем можете ,пожалуйста .мой адрес
olegtexas@inbox.ru

← →
sniknik © (2005-11-04 13:00) [1]

забив память ненужными данными ты не увеличиш скорость скорее уменьшиш. (врядли конечно, система разрулит, но небольшая вероятность все же есть ;)

ты же не ежесекундно к этим данным обращаешся, значить чаще всего они не нужны.

а ускоряют работу с базой несколько другими методами, нормализацией базы, продумыванием оптимальной структуры, созданием индексов по полям участвующих отборах, сменой принципов работы с базой (если с клиент серверной работать как с локальной то скорости не жди) и т.д.

← →
oleggar © (2005-11-04 13:40) [2]

Я уже думал подключить индексы (они есть физически ,это *.ntx CLipper) -но я не знаю ,как BDE использует индексы.С этим поможете ?может ,будет лучше .а нормализовать базу нет смысла ,там связей нет между dbf .и обращение идет 4 раза в секунду .Это система web-платежей ,и dbf -это банковские данные .Не я Clipper выбрал для них ,теперь это мое несчастье

← →
sniknik © (2005-11-04 14:26) [3]

http://delphimaster.net/view/3-1131016316/
думал переходить так переходи, говорил придется.
и также говорил, что BDE, эти индексы использовать не может (не читаем?).

> а нормализовать базу нет смысла ,там связей нет между dbf .и обращение идет 4 раза в секунду
нормализация не для того чтобы ускорить обращения а для того, к примеру чтобы данных стало меньше, менять проще (а работать сложнее ;).
возмем базу города, типа адреса кто где живет.
без нормализации можно представить одной таблицей, и будут в каждой строке все данные об абоненте. с названиями т.е.
округ, район, улица, дом, квартира, фамилия, имя, отчество. (грубо)
так вот. нафига писать. в 10 милионах записей "Северо-западный" в поле округ, если можно написать 1 раз? для чего таблицу придется разбить на две одну с именами округов а в основную вместо самого названия вставить ссылку (число 4 байта, прикинь экономию места...)
так мало того что это будет меньше места занимать так еще и индекс по округу будет не строковый а числовой, выборки по нему/связи быстрее... и т.д.
ну а если с одним полем стало лучше то почему и остальные так же не сделать? и вот у тебя вместо одной таблици стало 9... ;о) и сразу связи между ними понадобились... ;)

кстати почему бы твои таблици не рассматривать просто как входные данные для твоей программы? приходят они у тебя ночью говориш, ну цепляй их любым способом да перекачивай в нормальную базу с нормальной структурой (ночью времени хоть отбавляй;), днем работаеш с ней. и все. в принципе можноне все перегонять а только изменения (есть же признак? дата, время. определить новое) так и ночное время работы подсократиш...

← →
oleggar © (2005-11-04 15:31) [4]

я думал о перекачке в Interbase ,но хочется попробовать memorytable .может ,скорость фантастически выростет

← →
sniknik © (2005-11-04 16:12) [5]

> может ,скорость фантастически выростет
наивный... ;о))

фантастически не вырастет, можно говорить только о "приемлемой скорости" при таком подходе, да и то только изза того что неправильно работаеш с оригинальными таблицами.

ну хорошо, попробуй, сделай так
кидаеш 3 коммпанента в датамодуль
TADOConnection, TADODataSet и еще один TADODataSet %) (таблици то две? -> "100000 и 400000")

в ADOConnection прописываеш свойства
ConnectionString - "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\;Extended Properties=dBase IV;Persist Security Info=False"
LoginPrompt - false
(база типа на D:\)

e TADODataSet - ов
Connection - ADOConnection
LockType - ltBatchOptimistic
CommandText - SELECT * FROM Table1(/2/3 или как они там у тебя называются)
остальные свойства пусть останутся по умолчанию.
все, после открытия получиш свои таблици в памяти..., и чтобы с ними не делал, оригинал не запортится... (не делай только UpdateBatch, ну или после открытия можно "оторвать" коннект, Connection:= nil, тогда вообще что угодно ;)

и пару советов по "ускорению"
поля по которым будеш делать фильтры/связи (мастер детайл)/поиск, лучше проиндексировать (там же в памяти ;)
т.е. сделай сразу после открытия (окрывать не дизайне а по onCreate к примеру) ADODataSet.Sort:= "Имя поля"; для каждого такого поля. это создаст индекс и ускорит многие операции (некоторые без такого индекса просто не работают и потому создают его сами...)
ну и обащения к полям в циклах (особенно актуально) не делай через FieldByName делай либо индексно Fields[i], либо (еще лучше) в дизайне после присвоения всех параметров кликни два раза на компонент ADODataSet и создай поля (по правой конопке add all fields) и обращаяся по ним.
SQL-я как такового конечно не будет, но многое можно заменить фильтрами, т.к. таблица все одно в памяти это не будет отходом от клиент серверных методов (перекачки всего и последующей фильтрации вместо маленькой выборки), т.е. так тебе можно будет делать не боясь тормозов...

ну. давай, в добрый путь. ;`)

а что ругается Delphi на "could not find installed ISAM" ,когда АДО пускаю ?
что это и где взять ?

ISAM это "dBase IV" для провайдера jet, с которым работает ADO (что указано в строке вначале Provider=... )

не находит, значит неверно переписал/исправил строку конекта ("dBase IV" родной исам для джета, "брать"/отдельно ставить не надо. если есть jet 4.0 то есть и он (если конечно в реестре не ковырялся с целью "почистить" лишнее))

возможно путь менял и разделитель ";" снес.

memorytables Найти похожие ветки