AXAE softwarer AXAEА если куча большая - даже человек в сотне вещей будет перебирать практически все вещи по порядку,
Да ладно тебе. Он просто развалит ее по принципу половина-направо, половина-налево и снова увидит нужное :)

Но именно поэтому начиная с определенного размера кучи человек раскладывает ее по полкам в шкафу (читай - по большему количеству тех же куч). Для малоселективных критериев (а твой флаг - из таких) партиционирование - один из вариантов эффективного выбора.

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

Да понятно... Но раз уж я взялся - работать надо(( Я делал "как естественней" - я запутался... Таблицы появляются как грибы по мере того, как появляются все новые и новые условия задачи.((
Просто здесь на предприятии никто до конца не может объяснить, что собственно надо от базы данных (причем упоминается, что сейчас одно, а завтра может быть другое), поэтому я трепыхаюсь с ее структурой... Я видел где-то здесь на форумах мысль, что таблицы с динамически изменяемым набором атрибутов не нужны, что если появляются такие мысли - предметная область не до конца определена. Я согласен с этим - если полностью определенная предметная область, то проблемы вряд ли могут быть - но считаю так: к сожалению то, что если предметная область до конца не определена - это не является уважительной причиной отказа от разработки... ((
В такой ситуации поможет только бюрократия :), все требования к системе только в письменном виде как минимум с подписью специалиста из предметной области и его начальника, никчему
брать на себя ответственность за предметную область. А насчет "(причем упоминается, что сейчас одно, а завтра может быть другое)" заказчик должен четко понимать что система
пишется под конкретную задачу с конкретными требованиями, если требования не определены
четко то SAP им в помощь :-)

По поводу таблиц, как уже писали их должно быть столько сколько нужно, при сливании таблиц
связи в одну решающую роль должно играть на сколько эти связи совместимы, если остальные
аттрибуты и ограничения на них одинаковы то можно и слить а если разные, то ты просто не
сможешь реализовать ограничения стандартными средствами СУБД.

mir ViktoriankaА что ссылочную целостность уже отменили или как вы ее собрались поддерживать с одной таблицей связей?Присоединяюсь. В "решении" с одной "отфлажкованной" таблицей связности не задашь декларативно внешние ключи.
А это почему, можно примерчик?

mirПотому, что внешний ключ по определению ссылается на ключ конкретной таблицы. Явно указанной таблицы. И его нельзя декларативно задать так, чтобы он ссылался на ключи разных таблиц. Синтаксис:
ref_table может быть только одна.
Так два же поля одно на одну таблицу ссылается, другое на другую, какие проблемы то?

mir OraDen mirПотому, что внешний ключ по определению ссылается на ключ конкретной таблицы. Явно указанной таблицы. И его нельзя декларативно задать так, чтобы он ссылался на ключи разных таблиц. Синтаксис:
ref_table может быть только одна.
Так два же поля одно на одну таблицу ссылается, другое на другую, какие проблемы то?Специально для ваc скопировал исходную постановку задачи. Жирным я выделил ключевой момент:
AXAEесть таблицы T1, T2, T3. Отношения между ними: T1#T2=M:M, T1#T3=M:M. То есть нужны еще две таблицы связей. Что лучше с точки зрения производительности: две таблицы связей или лучше иметь одну, но с флажком: в ней будет одно поле для id первой T1, затем еще одно поле - id записи одной из двух других и еще флажок, значение в котором будет показывать, какой же именно из вторых таблиц записано в таблице связей второе id?
Извиняюсь, я тот пост не очень внимательно прочитал, запихнуть в одно поле ссылку
на все таблицы, у меня это даже в голове не укладывается... Хотя когда то давно я прикидывал
что любую базу можно запихнуть всего в несколько таблиц, только работать то потом как с ней...

AlexTheRavenМой Вам совет - на занимайтесь ранней оптимизацией: старайтесь соблюдать 3НФ.
+1

to AXAE
А то дойдете до того что нужно всего четыре таблицы - таблицу типов,
таблицу объектов, таблицу связей между объектами и таблицу связей между связями
и все с рекурсией ))