Знаю, что эта тема уже поднималась, но хочется кое-что уточнить. Вот приблизительная постановка задачи, которая у меня возникла.

Пусть есть некий класс объектов A , и класс объектов B , являющихся "разновидностью" A , но имеющих большее количество атрибутов. Держать их в одной таблице не хочется, и вроде бы естественной является мысль организовать связь 1:1. Поскольку у них есть "подчиненные" объекты, то держать A и B в несвязных таблицах тоже нехорошо. Для юзера эти объекты совершенно разные, то есть просматривать и редактировать A (которые не являются B ) и B он должен отдельно.

Опишу для начала то, как я решаю это на данный момент (синтаксис IB'шный, но вроде без особой специфики):
Потом идут триггеры на вьюшках, делающие их редактируемыми. Пользователи не имеют никаких прав на таблицы, только на вьюшки.

Собственно, основная проблема, которую я здесь вижу - это anti-join в V_A , который, по-видимому, может очень сильно тормозить. Сначала я хотел даже сделать примерно так:
, но потом понял, что избавляясь от проблемы идентификации "тех A , которые не B ", я получаю кучу других проблем. Единственное, что сейчас приходит в голову - держать в A признак того, что объект является B , т.е., что у него в B есть подчиненная запись. Сделать это несложно, а невозможность артефактов обеспечат вьюшки со своими триггерами, но это нарушает нормализацию.

Какой, по вашему мнению, более правильный вариант? Или, возможно, более правильное решение задачи в целом?

MasterZivЗачем NOT EXISTS ? Все B являются также и A. Поэтому во view, которое представляет A, нужно иметь также и экземпляры B.
С точки зрения "реального мира" (и юзера) есть объекты B , и есть A , которые не B , поэтому не так.

Old NickПри показе класса А в виде списка объекты класса В должны присутствовать, но не быть редактируемыми.
См. выше.
Old NickВ таблице А можно ввести тип, определяющий класс объектов. К тому же если тебе нужны будут только объекты типа А (без наследников), то можно будет список фильтровать по типу.
Я в первом посте сказал, что это основной рассматриваемый вариант. Но все-таки денормализация...

MasterZivЕсли тебе нужно выделить чистые A, то лучше сделать еще одного наследника от A - скажем, C, который будет играть роль тех объектов, которые сейчас у тебя являются чистыми A.
Тогда, теоретически, могут появиться такие A , ктороые не являются ни B , ни C . Да и избыточность получается больше, чем если вводить в A признак.

MasterZiv Павел Воронцов
Ну и что ты советуешь ? Вычитание - оно все равно вычитание, как его не записывай, в виде NOT EXISTS или в виде LEFT OUTER JOIN. Один фиг долго.

А действительно ли один фиг? По крайней мере, это выглядит изящнее, чем мой вариант. Я просто не уверен в том, насколько одинаково воспримет эти запросы FB'шный оптимизатор.

ololА если нужны разные фильтры для выборки, то и должны быть все признаки не в одной строке, а в виде таблицы перечня свойств... и для них таблица-фильтр...
Тогда можно будет спокойно добавлять и A_Attrib_3, A_Attrib_4...
Все-таки, заводить свои метаданные, и организовывать, по сути, собственную БД поверх существующей, не стоит, если нет реальной необходимости. Хотя в другом месте в этой задаче такая фигня у меня есть.

funikovyuriДля такой реализации наследования вам стоит почитать про descriminator'ы. А то какая-то частичная реализация получается - осюда и проблемы
А не подскажете, где о них почитать? Что-то я, видно, не смог правильный вопрос гуглю задать.

LVU funikovyuriДля такой реализации наследования вам стоит почитать про descriminator'ы. А то какая-то частичная реализация получается - осюда и проблемы
А не подскажете, где о них почитать? Что-то я, видно, не смог правильный вопрос гуглю задать.
Вроде нашел, приблизительно: http://blog.hibernate.org/cgi-bin/blosxom.cgi/Gavin%20King/discrimination.html . Но в этой статье, ИМХО, как раз получается приблизительно то же, что у меня, с поправкой от Павла Воронцова, за исключением того, что я не ввозу дискриминатор явно, а использую его неявное значение во VIEW.

iLLerПоясню, если объект А - это объект "свтильник", а В - это объект "светильник настольный", то очевидны проблемы, если наш "завод" вдруг начнет выпускать "стол". А вот если объект А - это "описание товара", а В - "проверенное и дополненное описание товара", то тут возможно расширения не предвидится.

Вот, очень близко ко второму варианту, на самом деле.

iLLerВ общем случае структуру можно сделать такой:
...


Подобную штуку предлагал olol (если я правильно его понял), и, как я ему уже сказал, она используется в этом проекте, но в другом месте. Здесь, я уверен, она совершенно не нужна.

iLLerВывод такой: анализируйте предметную область(или читайте ТЗ, здесь оно будет как нельзя кстати) и ищите золотую середину.
Насчет ТЗ я согласен, но его нет :( Сами ставим, сами пишем... А насчет предметной области - стараемся. Как я уже сказал, расширение номенклатуры объектов здесь невозможно, просто "по построению".

Павел ВоронцовРискну предложить ещё один вариант.
Интересный вариант, такая себе дополнительная жесткость образуется. Но при этом в B все равно могут быть записи, причем с любым значением TYPE, на которые никто не ссылается. Для моего случая точно не подходит, но если подклассов много - сгодится, наверное.

Павел Воронцов
А вот зачем это нужно, я не понял. Мне, по крайней мере, показалось, что "суперкласс" - это B , у него "подклассы" - B1 и B2 . При чем здесь вообще A ?

funikovyuriНужно учиться работать с гуглом http://www.google.ru/search?hl=ru&q=discriminator+column&lr=
<skip>
вот кусок документации к hibernate
<skip>
Если коротко - discriminator column - это поле определяющее класс к которому принадлежит данная запись-объект
Это я видел, но оно довольно малоинформативно. А в статье discrimination.html , которая к hibernate, видимо, какое-то отношение имеет, объясняют доходчиво и на примерах :) У меня, по-видимому, стратегия "table per subclass", в которой, согласно и тому, что читал я, и тому, что писали вы, использовать физическое поле для дискриминатора необязательно. В статье предлагают в таком случае вычислять его примерно так, как советовал Павел Воронцов. Поскольку собственно значение дискриминатора мне использовать не нужно (мне бы только выборку), то фактически, я его неявно ввожу как вычисляемое :)

Павел ВоронцовЭто вариант ссылки на суперкласс. Когда я такое ваял меня спрашивали "А вот как бы сделать так, чтобы была ссылка либо на одну либо на другую таблицу". Такой вот был вопрос.

Понятно :)

Павел ВоронцовНаличие "объектов" "суперкласса" без конкретных подтипов - проблаема решаемая. Если бы Вы работали с Ораклом и/или МС, я бы подсказал конкретные пути. А ФБ не знаю, увы.
Давайте для Оракла и/или МС, с ними я тоже работал. Все это не имеет отношения к моей задаче, т.к. держать практически пустую таблицу для "чистых" объектов A ИМХО глупо, но в целом интересно, какое там решение.

funikovyuri Павел Воронцов

Уважаемый - а CONSRAINT B_UK разве не лишний?

Рискну ответить за него - без B_UK не удастся сделать B1_FK и B2_FK, т.к. Foreign Key должен "смотреть" либо на Primary Key, либо на Unique (по кр. мере в FB, в остальных не помню. Но это, вроде, логично?)

funikovyuri
LVU

У Павла есть дескриминатор - это поле тип. Я за дескриминатор, так как он позволяет работать с иерархиями наследования на стороне сервера БД очень эффективно и практически за даром. Насчет того что hibernate может для table per class работать без него это хорошо - НО этого так просто не сможете вы на стороне сервера без каких-то других систем метаданных
Когда я говорил о предложении Павла, я имел в виду этот вариант anti-join'а. Собственно, anti-join и есть та единственная "система метаданных", которой эта схема отличается от использования дискриминатора. Впрочем, именно к дискриминатору я сколняюсь. Надо будет еще провести тест скорости, насколько этот anti-join тормозит.