iBase.ru Forum

Если внешний ключ является одним полем, например, целым,
То FB создает автоматический индекс по этому полю.
Но если я хочу составной индекс по этому же полю и плюс какое-нибудь другое., то мне придется создавать отдельный индекс.
Но два индекса слишком накладно ведь для внешнего ключа пригоден и второй составной индекс. Я знаю что автоматический индекс можно определить как составной если отрtдактировать
таблицу RDB$INDEX_SEGMENTS и еще одну таблицу. Тогда в итоге мы получим один индекс, но является ли это правильным?
И как вообще решать такие ситуации?

Отредактировать rdb$pages и rdb$transactions

Я знаю что автоматический индекс можно определить как составной если отрtдактировать
таблицу RDB$INDEX_SEGMENTS и еще одну таблицу.

ну-ну. может лучше файл базы сразу удалить, и не мучиться?

Но два индекса слишком накладно

накладно как - мучительно больно осознавать что в базе что-то "лишнее", медленнее работает, или еще что?

накладно в том смысле, что создается два индекса, там где на мой взгляд можно обойтись одним. И наверняка поддержка двух индексов требует больше ресурсов чем поддержка одного. Я конечно могу быть не прав, вот это я и хочу понять

xaoc писал(а):накладно в том смысле, что создается два индекса, там где на мой взгляд можно обойтись одним. И наверняка поддержка двух индексов требует больше ресурсов чем поддержка одного. Я конечно могу быть не прав, вот это я и хочу понять

да, больше ресурсов требуется, но насколько тебя это волнует?
хаос, он и в африке хаос

если можно вписаться в один индекс вместо двух то почему бы не сделать один, ведь может быть это не одна таблица, а например около 200. И на одно таблице может быть несколько внешних ключей тогда число индексов будет уже велико.

если можно вписаться в один индекс вместо двух

не "можно", и тебе об этом сказали.

прежде чем вещать про "накладно", выяснил бы, сколько занимает доп. индекс, и насколько он накладен для скорости работы.

а например около 200. И на одно таблице может быть несколько внешних ключей тогда число индексов будет уже велико.

убиться можно. значит, надо все внешние ключи удалить?

тогда буду выяснять

тогда буду выяснять

я бы посоветовал в данный момент вообще ничего не выяснять. Просто принять авто-индексы по ПК и ФК как данность, и строить свои индексы, которые действительно нужны, а не просто "так показалось" или "где-то слышал".

то есть, не надо пытаться экономить там, где эффекта от экономии почти не будет (может и вообще не будет, это зависит от объемов данных).

согласен, это вероятно у меня от общения c не SQL - ным
доступом к базам Pervasive