Dmitri Kuzmenko пишет:
Расскажи пожалуйста, в каких случаях его корректно использовать а в
каких нет.
на ibase.ru ищешь слово db_key, и находишь примеры:
http://www.ibase.ru/devinfo/dataaccesspaths.htm
http://www.ibase.ru/devinfo/updsame.htm
http://www.ibase.ru/devinfo/deldupes.htm
http://www.cvalde.net/document/mysteriousDbKey.htm
http://www.cvalde.net/document/practical_use_of_the_rdb.htm
Пасиб!
Пошел курить... ;-)
По моему, каждая фича должна быть хорошо задокументирована.
Нормальной документации по RDB$DB_KEY сейчас нет.
потому что это внутренняя фишка.
Однако наружу торчит ;-)
Есть несколько примеров, где описано как с его помощью получить лучшую
производительность.
сильно лучшую, слегка лучшую или как?
В http://www.ibase.ru/devinfo/updsame.htm говориться об ускорении в 150
раз на 3000 записей!
А Дмитрий Елманов говорит "Выигрыш в десяток процентов" - что на больших
табицах тоже может быть существенно. ;-)
Естественно хочится применить и в других случаях, по аналогии...
Но почему-то "аналогия" не всегда прокатывает.
это же НОМЕР ЗАПИСИ. в SQL по номеру записи не ориентируются.
Однако в http://www.ibase.ru/devinfo/deldupes.htm приводятся запросы с
подзапросами, в которых фигурирует RDB$DB_KEY
А в http://www.cvalde.net/document/mysteriousDbKeyII.htm
for select с фразой join и RDB$DB_KEY...
Что не так в приведённом мной запросе?
А так - от фичи больше вреда чем реальной пользы. ;-(
обычно если что-то недокументировано, то это автоматически
не рекомендуется к массовому использованию.
Однако же из 3х приведённых русскоязычных статей, только в updsame.htm
ксть что-то похожее на предупреждение (о длинне), но везде говориться об
ускорении доступа.
Т.е. опять же, хотелось бы, чтобы про грабли и ограничения было написано
немного больше.
