 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : oleg taranov 2:464/44 10 Feb 2002 13:12:23 To : Vladimir Pavlikov Subject : Проблемы persistent layers -------------------------------------------------------------------------------- 10 Feb 02 05:15, Vladimir Pavlikov wrote to oleg taranov: >> VP> Вообще для каждого. Для которого м.б. ссылки. Занимают немного, >> VP> да и - обычная расплата объемом за ээфективность. >> почему немного? тот же индекс только плоский - в зависимости от >> VP> условий >> может быть разного размера и если учесть что могут быть >> дубли то размер уже достаточно ощутим VP> Тот же индекс - те же расходы. С учетом эффективности никто индексы VP> расходами не считает, скорее наоборот :) наверно до тех пор пока индексы не занимают половину базы ;) VP> А о каких дублях речь? Указатель на владельца - тот же форинкей, VP> ровно VP> один для записи. Только он показывает _прямо_, а не через ПК, который VP> в мастер-таблице еще нужно найти (хоть бы и через индекс). то есть - на каждую запись по персональному fk? в обычном варианте - пара индексов на связку >> VP> Индекс, пусть кластерный, это : >> VP> 1. _Конкретное_ поле (их группа). >> VP> 2. Расходы на перебалансировку деревьев при модификациях. >> VP> 3. Работа по схеме индекс+запись. >> >> VP> Т.е. не везде применимо и гарантированно менее эффективно. >> в противовес можно посчитать расходы на обновление каждого >> списка при модификациях - а так же на содержание/обработку >> объектов при большом колве объектов и записей имхо это должно >> тормозить VP> Можно, но не нужно :) Вставка в список - атомарная операция. В отличие VP> от балансировки дерева, с его возможной эскалацией по уровням. так ведь от колва списков зависит -- и потом - нужно определить какие списки апдейтить а это уже похоже на фулсканы VP> И - что за объекты, Метелицы наслушался? :)) VP> Просто записи, только "знающие"своих владельцев "в лицо", по всем VP> наборам, в которые запись входит. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ну нужно как то это все называть ;) имхо объект короче ;) просто надо о терминологии договорится ;) VP> Кроме того, никто тебе не запрещает использовать обычные индексы в VP> случаях, когда для операции они удобнее. Это не замена, а дополнение. это меняет дело - поскольку есть разница между фичей и концепцией ;) >> VP> Первые реализации были в начале 70-х, если не в конце 60-х :) >> >> ну а довели это до реализации? иными словами - в каком сервере >> чтото похожее реализовано дабы посмотреть ;) VP> www.raima.com Впрочем, для получения общей информации [на родном VP> языке] можно почитать статьи на интерфейсе, на тему db_Vista->RDM-> VP> RDS->ROM[++]->Velocis. thx за ссылку /tff --- Be vigilant - I'mnt member of club i'm phantom! * Origin: TFF&F (2:464/44) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/14433c6664ad.html, оценка из 5, голосов 10
|
|
|