Nullable foreign key
Как-то в документации по Hibernate встретил вот такую фразу
Nullable foreign keys are not considered good practice in traditional data modelling, so all our examples use not null foreign keys. This is not a requirement of Hibernate, and the mappings will all work if you drop the nullability constraints.
http://www.hibernate.org/hib_docs/v3/reference/en/html/assoc...
п. 2 б/п
В том примере, который приводишь ты, лучше Description вообще в таблицу Product засунуть из моск не ломать.
В том примере, который приводишь ты, лучше Description вообще в таблицу Product засунуть из моск не ломать.а как же: "Описания часто повторяются" ?
может это двухгиговые описания
А ты понимаешь, что эти две таблицы не эквивалентны одной таблице productId, description?
Как лучше обрабатывать ситуацию, когда описание не задано.Надо понять, что это означает логически - что описания нет, или что описание есть, но пустое.
Наверное, у тебя всё-таки второй случай.
А ты понимаешь, что эти две таблицы не эквивалентны одной таблице productId, description?да
. Т.е. логика именно такая, что если меняем description, то он меняется у все продуктов с ним связанными.Надо понять, что это означает логически - что описания нет, или что описание есть, но пустое.а ты можешь за меня это понять и выбрать вариант?
P.S. ничего дополнительного вроде как не надо знать, да я и сам ичего кроме того, что написал, не знаю
а ты можешь за меня это понять и выбрать вариант?Ну я же не знаю, что у тебя там за задача.
В данном случае, наверное, выбрал бы второй вариант - тем более, эти описания сами по себе ничего не значат.
Оба варианта могут подойти, в зависимости от специфики твоей задачи.
Потом к этим таблицам писать запросы придется. Реши, как удобней будет с точки зрения производительности базы их связывать, с присоединением или без.
Еще момент. ProductDescription - это простой справочник типа код/значение. В нем однозначно не должно быть незаполненных полей. Если уж очень хочется завести подобную запись, то напиши значение "Нет информации", "Не указано" и т.д. (что по смыслу подойдет) И используй его.
Потом к этим таблицам писать запросы придется. Реши, как удобней будет с точки зрения производительности базы их связывать, с присоединением или без.
Еще момент. ProductDescription - это простой справочник типа код/значение. В нем однозначно не должно быть незаполненных полей. Если уж очень хочется завести подобную запись, то напиши значение "Нет информации", "Не указано" и т.д. (что по смыслу подойдет) И используй его.
Если уж очень хочется завести подобную запись, то напиши значение "Нет информации", "Не указано" и т.д. (что по смыслу подойдет) И используй его.это повлияет на текстовый поиск (пока это LIKE) и на сортировку. Желательно, чтобы эти пустые значения были вверху списка, NULL-ы как раз и выводятся в начале списка. Прикручивать ради этого специяльное поле для сортировки как-то не хочется.
P.S. можно на UI-е NULL-ы как-то помечать фразой или цветом....
Задача к сортировкам результата запроса что ли свелась?
Поставь/начни фразу с прочерка или фигурной скобки, например ([Не указано]).
Поставь/начни фразу с прочерка или фигурной скобки, например ([Не указано]).
А ты заведи себе Специальный Нулевой Дескрипшн (ну, там, гуид сгенери в качестве описания, или зафиксируй DescriptionId как-нибудь где-нибудь). На который будут ссылаться все продукты, у которых тебе хотелось бы прописать нулл.
Когда я это предложил, мне стало ващеее совершенно непонятно, как это у некоторых продуктов может быть общий дескрипшен и кто это решает, что он действительно общий.
Когда я это предложил, мне стало ващеее совершенно непонятно, как это у некоторых продуктов может быть общий дескрипшен и кто это решает, что он действительно общий.
а почему нельзя просто в таблице description сделать ссылку на product ID? Тогда и полей меньше и с nullable морочиться не нужно. Будет нормализация со связью один ко многим
По условию один дескрипшен к нескольким продуктам может относиться.
Связь разворачивать нельзя.
Либо делать много-ко-многим через доп. таблицу.
ЗЫ. Не хотел бы поддерживать ТАКОЕ
Связь разворачивать нельзя.
Либо делать много-ко-многим через доп. таблицу.
ЗЫ. Не хотел бы поддерживать ТАКОЕ
Фаулер для этого даже название специальное придумал - Special Case.
Но чем это в данном случае лучше простого null-значения?
Но чем это в данном случае лучше простого null-значения?
если меняем description, то он меняется у все продуктов с ним связаннымиПравило распостраняется на записи с нулевым дескрипшном?
Правило распостраняется на записи с нулевым дескрипшном?Молождец, возьми с полки пирожок!
Действительно, похоже, что здесь надо использовать именно nullable fk, а не специальную запись.
Правило распостраняется на записи с нулевым дескрипшном?нулевой дескрипшен можно сделать read-only.
Склоняюсь все-таки ко второму варианту. В запросах как-то привычнее писать INNER JOIN, чем LEFT OUTER JOIN. Да, в рекомендациях по пефомансу пишут, что OUTER JOIN-ов должно быть как можно меньше.
нулевой дескрипшен можно сделать read-only.это как?
на UI
Оставить комментарий
6yrop
Есть сущность Product, у нее есть атрибут Description. Описания часто повторяются, удобно вынести Description в отдельный таблицу-справочник ProductDescription.Как лучше обрабатывать ситуацию, когда описание не задано.
1. Сделать поле Product.ProductDescriptionId налебл.
2. Завести в таблице ProductDescription специальную запись с пустым значением.