2 c127
c127join в данном случае ни при чем... Я хотел сказать, что внешний ключ еще не позволяет добавлять в дочернюю таблицу записи, у которых нет ссылки на родительские... к оптимизации это прямого отношения не имеет
Имеет прямое. В Visual FoxPro точно. За Accces пусть авторитетно скажут те, кто с ним работает. Уверен, что скажут они то же самое. Поддержание ссылочной целостности реализовано за счет активного использования соответствующих индексных ключей. Т.е. _оптимизировано_.
Вот кусок стандартного триггера на каскадное удаление, который генерит Visual FoxPro на основе штатного генератора RIBuilder, отвечающего за поддержку ссылочной целостности в Базе данных
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Открытие фоксом дочерней таблицы с активным тегом (индексом) menulst_id - внешний ключ
lcChildWkArea=riopen( "menus" , "menulst_id" )
.............
SELECT (lcChildWkArea)
* SEEK - команда работающая только с индексом. Ищется первое вхождение
* родительского ключа во внешнем ключе дочерней таблицы
SEEK lcParentID
* Сканирование всех дочерних записей по внешнему ключу и их удаление
SCAN WHILE MENULST_ID=lcParentID AND llRetVal
pnChildRec=recno()
pcChildID=MENULST_ID
pcChildExpr= "MENULST_ID"
llRetVal=ridelete()
ENDSCAN get all of the menus records
c127Не знаю индексирует ли такие поля акцес, но это не важно.
Очень даже важно, иначе на больших таблицах будет тормоз.
c127join в данном случае ни при чем
Я имел в виду то, что поскольку SELECT использует индексы, и поскольку JOIN - операция производящаяся по ключам, то эти индексы используются оптимизатором в первую очередь, т.е. тянутся по сети
Что с файл сервером ни делай - страдает сетка. Клиент-серверу в данном случае легче, ему вообще не нужно оптимизировать сетевой трафик.
Это да. Так и есть
Потом если вытащил индекс на клиент d (полностью или частично, не важно) - блокируй таблицу, иначе положение записи может измениться другим клиентом g и индекс находящийся у клиента d перестанет соответсвовать таблице.
Что значит "положение записи может измениться"? Значение индекса изменится всмысле? Ну и нехай изменяется. Синхронизация с сетевым источником в Файл-сервере происходит автоматом по определенному интервалу - я уже писал об этом. Зачем что-то блокировать? Тем более ТАБЛИЦУ. Для просмотра вообще ничего блокировать не надо. Для редактирования - надо, но только не таблицу, а нужную запись/записи. Как раз для того, чтобы разрулить юзеров, желающих править одно и то же.
Я вообще не понимаю, зачем сейчас использовать ФС, если есть очень неплохие, бесплатные и к тому же легкие (работают даже на палмах и не требуют инсталляции) SQL сервера.
Если Вы не против, я уклонюсь от ввязывания во флейм по поводу ФС vs. КС. Раз первый еще не подох, а активно развивается (Visual FoxPro 9 обещают в конце года и с Access в MS никто не собирается завязывать), то значит рынку это надо... Как только рынку это будет не надо - КС вытеснит ФС окончательно. Уж кто-кто, а MS точно за $ мать родную продаст, если почуствует, что его Файл-серверные направления приносят только убытки. И вообще "неплохие, бесплатные" - это довольно подозрительно :) Всё оно обычно бесплатно до первой же банальности, которую система делать будет не уметь, а тебе оно будет ОЧЕНЬ надо...
