 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : oleg taranov 2:464/44 12 Feb 2002 20:27:22 To : Vladimir Pavlikov Subject : Проблемы persistent layers -------------------------------------------------------------------------------- 11 Feb 02 03:07, Vladimir Pavlikov wrote to oleg taranov: >> VP> Тот же индекс - те же расходы. С учетом эффективности никто >> VP> индексы расходами не считает, скорее наоборот :) >> наверно до тех пор пока индексы не занимают половину базы ;) VP> Ты будешь смеяться, но как-то коллега сделал задачу _только_ на VP> индексах, не используя файлы данных вообще. Самое смешное, что в VP> той задаче это было наилучшее решение :) а это как? индекс то на основе данных строится и с онными только и работает >> VP> Вставка в список - атомарная операция. В отличие >> VP> от балансировки дерева, с его возможной эскалацией по уровням. >> так ведь от колва списков зависит -- и потом - нужно определить >> какие списки апдейтить а это уже похоже на фулсканы VP> Hе понял. От количества списков это никак не зависит - в любой момент VP> вставка идет в один. И списки "апдейтить" не надо - ты что, не в VP> курсе, что собой представляет вставка в двусвязный список? я пока не до конца понял идею давай еще раз: имееются записи - к каждой прилагается список по которому можно получить набор из другой таблицы теперь если верно то что я написал выше: делаем вставку записи в связанную таблицу как сделать вставку в списки? надо знать в список какой записи сделать вставку (кстати а где хранятся условия списков? могут ли они быть уникальными для каждого списка?) удаление будет быстрым если есть списки в связанной таблице VP> Это VP> быстрая операция, никак не зависящая от длины списка. собственно вставка - да >> VP> И - что за объекты, Метелицы наслушался? :)) >> VP> Просто записи, только "знающие"своих владельцев "в лицо", по >> VP> всем наборам, в которые запись входит. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> ну нужно как то это все называть ;) имхо объект короче ;) >> просто надо о терминологии договорится ;) VP> Hе надо - она есть. Есть понятие Hабор, его Владелец, его Члены : VP> record A{}; VP> record B{}; VP> record C{}; VP> set link{ VP> owner A; VP> members B, C; VP> } VP> Объекты тоже есть - в ROM, но это уже ОО-обвязка. well - давай пользоваться этой ;) /tff --- Be vigilant - I'mnt member of club i'm phantom! * Origin: TFF&F (2:464/44) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/14433c696dfe.html, оценка из 5, голосов 10
|
|
|