Я все еще не вижу примера таких задач. Вы мне изложили не постановку, а свое понимание реализации - через какое-то поле связи всего со всеми. Вы попытайтесь _внятно_ рассказать, что надо сделать, а как это сделать без двухсотпятидесяти таблиц в одном запросе мы уж придумаем. Попробуйте обойтись без слов "сущность", "объект" и "связь" - замените их на что-то типа "Вася", "яблоко" и "принадлежит".

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

guest_20040621
Все правильно. Теперь считаем. Как я и говорил, база данных среднего размера (единицы сотен таблиц; для определенности примем 500). Пусть это отношение имеет смысл для половины сущностей (опустили служебные таблицы и связи). Получаем 250 (двести пятьдесят) промежуточных таблиц. Создали таблицы, заполнили их. Теперь выбираем сущности, связанные с определенным словом. Как по-Вашему, какие проблемы меня здесь ждут?


Зачем вы разнесли сущности по пятистам таблицам ? У вас что, 500 разных словарей, и вы ищете слово по всем словарям ? Почему не поместить сущности в одну таблицу ?

1. Вы опять излагаете свою реализацию, а не постановку.
2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет дополнительно указываться "имя связанной таблицы".
3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали структуру базы. Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500 запросов, либо один Union запрос с 500 подзапросами. Второй вариант - для тех любителей острых ощущений, которые считают, что у оптимизатора их субд отменное здоровье и крепкие нервы.

guest_20040621> 2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет
> дополнительно указываться "имя связанной таблицы".

Нет, не лень. Просто смысла нет заводить 250 лишних таблиц. А вот одна таблица - это хорошо, только тогда как быть с ссылочной целостностью? А удаление/добавление/хранение истории? А версионность структуры данных?

> 3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали
> структуру базы.

Уверяю Вас, это не так. 3 н. ф. - как норма проектирования.

> Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500
> запросов, либо один Union запрос с 500 подзапросами.

Не хочу. Эффект разреженной матрицы: запрос вернет очень немного записей. Из пушки по воробьям.

3 нф - не панацея от неправильного проектирования.
Если у вас однотипная информация разбросана по 500 таблицам - то со структурой явно что-то не так.
Не вижу никаких проблем с удалением, добавлением и изменением записей - все как обычно, транзакцию открыли, добавили в одну, вторую, промежуточную - транзакцию закрыли. Если так хочется ссылочной целостности - в каждой из пятисот таблиц заведите FK на промежуточную таблицу, PK сделайте глобально уникальными - назначайте со сдвигом в 1000 для каждой таблицы (в первой - 1, 1001, 2001..., во второй - 2, 2002, 2003...). С внезапно возникшей версионностью делайте что хотите, обычно она нахрен не нужна, но если сильно хочется - заводите архивы.
Если так сильно ломает опрашивать все пятьсот таблиц - заведите одну и в ней храните, в какой таблице слово встречается. Потом динамически генерируйте селекты и вперед.
Я одно не пойму - куда вы клоните ? Сначала вы рассовали однородную информацию в пятьсот мест, а теперь жалуетесь, что ее трудно собирать. Ну дык ! А когда вам говорят, что не надо ее рассовывать - вы меня уверяете, что все сделано правильно.

guest_20040621> 3 нф - не панацея от неправильного проектирования.
> Если у вас однотипная информация разбросана по 500 таблицам - то со
> структурой явно что-то не так.

С чего Вы взяли, что я разбросал однотипные данные по 500 таблицам? - нет, все хорошо и с нормализацией, и с описанием.

> Не вижу никаких проблем с удалением, добавлением и изменением записей -
> все как обычно, транзакцию открыли, добавили в одну, вторую,
> промежуточную - транзакцию закрыли.

Да я тоже проблем не вижу. Хотелось, чтобы Вы это сформулировали. ;)

> Если так хочется ссылочной целостности

;)

> - в каждой из пятисот таблиц заведите FK на промежуточную таблицу, PK
> сделайте глобально уникальными - назначайте со сдвигом в 1000 для каждой
> таблицы (в первой - 1, 1001, 2001..., во второй - 2, 2002, 2003...).

Не пойдет. Никто не гарантирует, что 1000 записей для одной таблицы хватит.

> С внезапно возникшей версионностью делайте что хотите, обычно она нахрен
> не нужна, но если сильно хочется - заводите архивы.

;)) Хм... у меня версионность внезапно не возникает. На самом деле еще много подзадач есть; мы ж не конкретный проект обсуждаем, а все-таки надстройку, правда? - чего ж я буду несущественными деталями грузить? О чем это я? Ага, версионность. Мне казалось, что обычно она как раз нужна. Ладно, забудем версионность.

> Если так сильно ломает опрашивать все пятьсот таблиц - заведите одну и в
> ней храните, в какой таблице слово встречается. Потом динамически
> генерируйте селекты и вперед.

;) Н-да, про версионность я рановато забыл. В общем, Вы так или иначе сказали то, чего я от Вас добивался: используем одну таблицу. В общем неважно, что и как там хранить, имена таблиц со словами и идентификаторами или просто идентификаторы; отметим факт: имеем некоторую таблицу, которая по некоторым правилам позволяет нам связывать таблицы базы данных.

> Я одно не пойму - куда вы клоните?

Все, уже закончил клонить. ;) Берем предложенное Вами возможное решение: используем одну таблицу для связей между "супертаблицей" и остальными таблицами базы данных. Весь требуемый функционал (ссылочную целостность, апдейты, динамические запросы и пр.) реализуем за пределами базы данных. Собственно, получили часть той надстройки, о которой я говорил. ;)) Я всего лишь чуть видоизменил _предложенное Вами_ решение. ;)) Возражения?

> Сначала вы рассовали однородную информацию в пятьсот мест, а теперь
> жалуетесь, что ее трудно собирать.

Да не рассовывал я ее никуда. Если мой пример не нравится, возьмите любую Вашу базу данных и попробуйте подключить к ней словарь. Ко всем таблицам, где это имеет смысл. Не то же самое получилось? ;)

С генерированием уникального ключа вы не поняли - я предлагаю не диапазон ключей выделать (1-1000 для первой таблицы, 1001-2000 для второй) а сдвиг и номер : для первой таблицы последние три разряда всегда 001, для второй - 002 и т.д. Так что для тысячи таблиц такой схемы вам должно хватить, а нет - увеличьте сдвиг.
Я последний раз повторяю : в нормально спроектированной системе не бывает запросов к пятистам таблицам одновременно. Можете принять это за аксиому. Или лучше поступим как с адиском - вы рассказываете условие, я придумываю схему без пятисот таблиц , мы сверяем производительность.

И какой такой словарь вы все время пытаетесь подключить "ко всем таблицам" ? Словарь чего ? Чем вас не устраивают systables / syscolumns ?

guest_20040621
> Я последний раз повторяю : в нормально спроектированной системе не бывает
> запросов к пятистам таблицам одновременно. Можете принять это за аксиому.

Вот здесь я с Вами абсолютно согласен. Действительно не бывает. Но связать эти пятьсот таблиц между собой - просто необходимо. ;))

> Или лучше поступим как с адиском - вы рассказываете условие, я придумываю
> схему без пятисот таблиц , мы сверяем производительность.

У Вас содержимое баз данных на русском языке? Подключите к любой из Ваших баз данных словарь Ожегова. Любым образом. Ничего сверять не нужно, нужна только схема.

> И какой такой словарь вы все время пытаетесь подключить "ко всем таблицам"?
> Словарь чего ? Чем вас не устраивают systables / syscolumns ?

;) Да при чем здесь системные таблицы? Я ж говорю, просто обычный языковой словарь. Как пример. Не хотите словарь, - давайте представим, что есть куча картинок, документов или еще чего. Что больше нравится?

Я как-то слабо понимаю что такое "подключите" в вашей трактовке.
Если вы собираетесь каждое текстовое поле проверять на наличие в словаре, то (забыв про различные формы одного слова) достаточно навесить триггер на вставку. Поскольку словарь - вещь статичная, то никаких каскадных удалений и RI не надо. А если вас интересует, в каких таблицах встречается данное слово - то заведите себе козу, пардон, таблицу формата слово/таблица, и вставляйте туда записи при insert в любую из ваших таблиц. В чем проблема-то ?

2 adisk :
Я знал, что вам понравятся 6 миллионов записей :-)
Как насчет select ? фокс фоксом, но хотелось бы увидеть текст запроса на SQL.
И, кстати, поля разных типов неплохо бы разнести по разным таблицам.

guest_20040621> Я как-то слабо понимаю что такое "подключите" в вашей трактовке.

Поздно было, спать хотелось. Под "подключить" имелись в виду связи. И связи не между таблицами, а связи к словарю, конечно же.

> Если вы собираетесь каждое текстовое поле проверять на наличие в словаре,

Yes! Получилось. ;))

> то (забыв про различные формы одного слова) достаточно навесить триггер на
> вставку.

Не, забывать про различные формы слова мы не будем. Будем корректны. Триггеры - триггерами, а связи нужны для того, чтобы иметь возможность сделать обратную выборку. Т. е. знать, в каких таблицах выбранное из словаря слово встречается.

> Поскольку словарь - вещь статичная, то никаких каскадных удалений и RI не
> надо.

Ну, положим, словарь действительно относительно статичный. Но данным в остальных таблицах ничто меняться не мешает. ;)

> А если вас интересует, в каких таблицах встречается данное слово - то
> заведите себе козу, пардон, таблицу формата слово/таблица, и вставляйте
> туда записи при insert в любую из ваших таблиц. В чем проблема-то ?

Да нет проблем. ;) Вы снова предложили решение с одной таблицей. Так я ж об этом Вам и пытался рассказать с самого начала. ;)) Т. е. в результате _Ваших умозаключений_ мы пришли к решению, которое 1. не является типовым для реляционной базы данных, 2. тем не менее хорошо формализуется и может быть реализовано в виде внешнего (к базе данных) модуля. Теперь, надеюсь, нет возражений? ;)) Вы же все сами сформулировали, - я только немного _Ваше решение_ причесал.

Проверка на наличие в глобальном словаре - это не совсем связь. Так что 250 промежуточных таблиц вам изначально были не нужны. Как и RI, целостность изменений, версионность и прочие страсти, которые вы рассказывали. Не вижу ничего, что делает эту задачу неудобной для реляционной бд. И решение совершенно типовое, первое, что приходит в голову. Над такими решениями проектировщик вобще не должен задумываться. Так что пардон, но ваш пример лично мне ничего не доказал.

guest_20040621> Проверка на наличие в глобальном словаре - это не совсем связь.

А где я связь считал тождественной проверке?


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

Хм... а и не было желания ничего никому доказать. ;) Было желание заставить Вас предложить такое решение, которое невозможно было бы описать в терминах "сущность" - "связь" без системных таблиц. Чего Вы очень не хотели, настаивая на традиционном связывании сущностей. Но что, собственно, практически без труда и получилось. ;) А нашли Вы в этом какие-то доказательства чего-то или не нашли, - мне лично совершенно наплевать. ;) Ы?

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