организация таблицы

Alexus12
Дата: 06.03.2007 10:29:43
есть необходимость в таблице:

text1 varchar2(50)
text2 varchar2(50)
id number(9,0)
fkey number(9,0)

по полям text1+text2 нужен уникальный индекс (по ним происходит "типизация" входных данных системы),
по полю id ('autonumber')- еще один уникальный индекс

при этом
поля text1+text2 используются раз в месяц для подгрузки данных
поля id + fkey - часто и постоянно, для соединения с двумя другими таблицами

вопрос: как лучше организовать таблицу и почему:
а) HEAP с двумя отдельными индексами = почти 2 копии данных
б) IOT по полям text1+text2 INCLUDING id + fkey (экономим место на большом индексе text1+text2, но IOT никак не ускоряет работу с id+fkey)
в) IOT по ID+fkey INCLUDING text1+text2, пожертвовав проверкой уникальности ID (заполнение будет идти из sequence), но все равно потеряв на индексе по text1+text2
...
?
SQL*Plus
Дата: 06.03.2007 10:59:51
Конкретизируйте цель, которую вы хотите достичь.
Alexus12
Дата: 06.03.2007 11:07:21
цель - баланс цены и качества ;)
не тратить двойное табличное пространство на хранение данных + индексов по тем же данным
и при этом использовать индексы
miksoft
Дата: 06.03.2007 11:11:50
Alexus12

в) IOT по ID+fkey INCLUDING text1+text2, пожертвовав проверкой уникальности ID (заполнение будет идти из sequence), но все равно потеряв на индексе по text1+text2
Почему "пожертвовав" и "потеряв" ? Вроде бы дополнительные индексы, в т.ч. уникальные, создавать никто не запрещает.
SQL*Plus
Дата: 06.03.2007 11:12:39
ОК. Тогда давайте цены - что у вас дешево, что дорого...
Что важнее, что не столь важно...
Без этого ваша цель расплывчата, как каша манная...
contr
Дата: 06.03.2007 11:20:01
miksoft
Alexus12

в) IOT по ID+fkey INCLUDING text1+text2, пожертвовав проверкой уникальности ID (заполнение будет идти из sequence), но все равно потеряв на индексе по text1+text2
Почему "пожертвовав" и "потеряв" ? Вроде бы дополнительные индексы, в т.ч. уникальные, создавать никто не запрещает.

У IOT не определен ROWID, только эрзац - "логический" rowid, представляющий собой первичный ключ IOT. Поэтому вторичные индексы IOT дороже обычных индексов HEAP-organized таблицы как в плане хранения,так и в плане доступа.
miksoft
Дата: 06.03.2007 11:25:19
contr
Поэтому вторичные индексы IOT дороже обычных индексов HEAP-organized таблицы как в плане хранения,так и в плане доступа.
Имхо, это зависит от задачи. В каких-то случаях это будет хуже, в каких-то нет... А с учетом экономии на хранении самой таблицы, думаю, доля вторых случаев не так уж мала.
Stax.
Дата: 06.03.2007 15:14:30
Alexus12

при этом
поля text1+text2 используются раз в месяц для подгрузки данных

перед заливкой создать индекс
залить
грохнуть индекс

зы
для защиты заливки без индекса,
мона защиту дописать
напр триггер
......
stax