ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Поддержка уникальности в таблицах, расширяющих родительскую.
23 сообщений из 23, страница 1 из 1
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344272
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
Добрый день!
Есть, допустим, сущность "Человек". "Человек" может быть либо "Врачом", либо "Пациентом" ( одновременно и тем, и тем, быть не может ). В голову приходит две реализации:
1) Из таблиц "Врач" и "Пациент" ссылаться на "Человека".
2) В таблице "Человек" добавить ссылки и на "Врача", и на "Пациента".
Первый вариант выглядит вроде бы предпочтительнее, хотя бы потому что второй нарушает 2 нормальную форму. НО! В первом варианте гораздо сложнее отследить что бы на "Человека" не было две ссылки из обеих связанных таблиц (и можно ли вообще сделать это стандартными sql средствами, не используя триггеры?). Вообще, проблемма совершенно стандартная и регулярно появляеться, поэтому должно же быть какое то "правильное" стандартно решение? Или, хотябы, на ваш взгляд, какой из двух вариантов лучше?
Для лучшего понимания прикладываю картинку, иллюстрирующую оба варианта.
...
Рейтинг: 0 / 0
02.12.2009, 17:55
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344371
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Jelis одновременно и тем, и тем, быть не можетСурово однако. Заболел, значит не достоин звания врача. Другое дело что в документе типа рецепт можно запретить чтобы врач = пациент
...
Рейтинг: 0 / 0
02.12.2009, 18:21
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344476
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
SERG1257Jelis одновременно и тем, и тем, быть не можетСурово однако. Заболел, значит не достоин звания врача. Другое дело что в документе типа рецепт можно запретить чтобы врач = пациент
Врачи в своих больницах не лечаться :-)
Ну, это пример о сферическом коне, но суть проблеммы передаёт полностью. На самом деле область у меня соовсем другая. Можно в примере заменить "человека" на "транспорт", а "врача" и "пациента" на "грузовой" и "легковой".
...
Рейтинг: 0 / 0
02.12.2009, 19:20
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344525
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Выцарапать общие признаки из сущностей легковая и грузовая машины в отдельный предок - транспорт идея конечно красивая, объектная, но я предпочитаю строить базы ориентируясь на непротиворечивость и удобство хранения/обработки данных ибо программы приходят и уходят а данные остаются.
Иными словами а задлянафига вам это надо?
...
Рейтинг: 0 / 0
02.12.2009, 20:02
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344566
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
SERG1257Выцарапать общие признаки из сущностей легковая и грузовая машины в отдельный предок - транспорт идея конечно красивая, объектная, но я предпочитаю строить базы ориентируясь на непротиворечивость и удобство хранения/обработки данных ибо программы приходят и уходят а данные остаются.
Иными словами а задлянафига вам это надо?
Ну, если в другой таблице нам надо ссылаться просто на "транспорт", и совершенно всёравно, "легковой" он или "грузовой". Например, есть "рейс", к которому привязан "транспорт" (любой) и "водитель". А вот сервисы есть раздельные, "сервис_для_грузового_транспорта" и "сервис_для_легкового_транспорта". И "страховки" совершенно разные, для разных транспортов. А даты смены колёс надо отслеживать только для "грузового" транспорта. А "техосмотры" проходят просто для всего "траспорта". Ну и ко всему этому "транспортов" может быть не два вида, а побольше.
И, имхо, объектного тут нет ни капли!
...
Рейтинг: 0 / 0
02.12.2009, 20:33
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344594
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Судя по всему Легковые и грузовые это отдельные сущности с некоторыми одинаковыми полями.
То есть таблица Транспорт плавно превращается во вьюху с объединением (union all) общих полей из таблиц Легковые и Грузовые.
Теперь про таблицу Рейс. Туда я бы засунул два поля (с разрешенными пустыми значениями) со ссылками на таблицы Легковые и Грузовые и ограничением типа только одно из них должно быть заполнено. Если добавляется еще одна таблица например Автобусы то добавляем еще одно поле и модифицируем ограничение.

Jelis И, имхо, объектного тут нет ни капли! Скажем так - подобные подходы к проектированию я видел у поклонников OOП.
...
Рейтинг: 0 / 0
02.12.2009, 21:09
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344619
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
Ага... Per aspera ad astra... Слегка удлиннёным путём, но вы высказались за второй вариант на картинке. Спасиба :-)
В таком варианте ("две ссылки на разные таблицы, только одна заполнена") весьма легко повесить check на таблицу для контроля условия. Но вот что меня смущает: это сходу нарушение 3 нормальной формы, так как получаеться что два этих поля зависят друг от друга, а не только от первичного ключа :-( А это есть грех, который хочеться по возможности всё таки не совершать :-)
А на счёт вьюшки "Транспорт"... Если у вас "легковые" и "грузовые" две полностью разделённые сущности с дублирующимися полями, как вы будете отслеживать, например, уникальность гос номеров? Они же должны быть полностью уникальными - не может у нас быть "легкового" и "грузового" с одинаковым номером!

SERG1257 Скажем так - подобные подходы к проектированию я видел у поклонников OOП.
Не переживайте - я до мозга костей поклонник РСУБД... Хотя на яве пишу много - может и начало уже её виляние сказываться :-)
...
Рейтинг: 0 / 0
02.12.2009, 21:44
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36344639
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Jelis Они же должны быть полностью уникальными - не может у нас быть "легкового" и "грузового" с одинаковым номером!В таком случае действительно имеет смысл ввести сущность Транспорт с общими полями плюс два nullable поля Свойства легкового автомобиля и Свойства грузового автомобиля плюс ограничение. То бишь перенести эту связь из таблицы Рейс в таблицу транспорт.

Jelis Ага... Per aspera ad astra... Слегка удлиннёным путём, но вы высказались за второй вариант на картинке. Спасиба :-)А вы поболее про задачу расскажите (типа популярные/критичные запросы) и я выскажусь и за первый или вообще за третий ненарисованный вариант.
...
Рейтинг: 0 / 0
02.12.2009, 22:10
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36345059
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Senya_L
Участник
SERG1257В таком случае действительно имеет смысл ввести сущность Транспорт с общими полями плюс два nullable поля Свойства легкового автомобиля и Свойства грузового автомобиля плюс ограничение. То бишь перенести эту связь из таблицы Рейс в таблицу транспорт.А завтра появится речной вид транспорта, а потом воздушный.
...
Рейтинг: 0 / 0
03.12.2009, 09:44
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36345367
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
Senya_LSERG1257В таком случае действительно имеет смысл ввести сущность Транспорт с общими полями плюс два nullable поля Свойства легкового автомобиля и Свойства грузового автомобиля плюс ограничение. То бишь перенести эту связь из таблицы Рейс в таблицу транспорт.А завтра появится речной вид транспорта, а потом воздушный.

Т.е. вы выступает за схему по первому варианту (на картинке)?
...
Рейтинг: 0 / 0
03.12.2009, 11:25
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36345404
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
SERG1257А вы поболее про задачу расскажите (типа популярные/критичные запросы) и я выскажусь и за первый или вообще за третий ненарисованный вариант.
В том-то и дело, что меня интересует не конктретный случай, а абстрагированое теоретическое "правильное" решенеий подобной ситуации, этакий best practice. При проектировании подобная схема у меня появляеться регулярно, наверно раза 3 на каждые 100 таблиц. И каждый раз приходиться в муках решать, как же лучше сделать :-)
Если вы скажете что я много хочу, и что надо смотреть на каждый конкретный случай, могу привести пример с отношением многие-ко-многим: тут без вопросов решаеться путём введения допонительной таблицы, и особо раздумывать не надо!
...
Рейтинг: 0 / 0
03.12.2009, 11:35
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36345940
Серж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серж
Участник
JelisВ первом варианте гораздо сложнее отследить что бы на "Человека" не было две ссылки из обеих связанных таблиц (и можно ли вообще сделать это стандартными sql средствами, не используя триггеры?).Бизнес логика не обязательно должна выполняться только средствами "чистого" sql. Закройте модификацию этих таблиц хранимыми процедурами и в них контролируйте целостность.

И вторая отправная точка для размышлений - как вы будете определять что конкретный транспорт "грузовой" или "легковой"? Если if exists(select * from "грузовой") then "грузовой" else "легковой"... А если по другому? Например, в таблицу "траспорт" добавить поле "тип транспорта".
...
Рейтинг: 0 / 0
03.12.2009, 13:55
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346592
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
Я за первый вариант, как раз НЕЧТО такое реализую, но у меня в дочерней таблице ParentID=ID, то есть первичный ключ дочерней таблицы является одновременно внешним к родительской.
Кроме того для каждой дочерней таблицы постороена VIEW по типу:
Код: plaintext
1.
2.
SELECT ChildTable.ID,ChildTable....,ParentTable....
FROM ChildTable
INNER JOIN ParentTable ON (ChildTable.ID=ParentTable.ID)
и навешены триггеры к нему, так что можно оперировать этой VIEW как единым объектом
С уважением, Naf
...
Рейтинг: 0 / 0
03.12.2009, 17:00
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346745
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Использую чаще всего первый вариант. Из соображений гибкости и "похожести" на ООП. :)
...
Рейтинг: 0 / 0
03.12.2009, 17:51
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346772
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Jelis И каждый раз приходиться в муках решать, как же лучше сделать :-) Такова твоя планида.
Плюс добавь что схема редко пишется/переписывается с нуля, всегда есть какая-то реализованная часть, плюс решение должно быть максимально простым и понятным, плюс решение должно быть "удобным" для СУБД (чтобы обеспечить приемлимую производительность), плюс просчитать что будет (что придется поменять) если условия игры изменятся. Так что однозначное идеальное решение в общем случае не найти.

Senya_LА завтра появится речной вид транспорта, а потом воздушный.Неизбежно добавится новая таблица, то бишь будет патч на СУБД в котором можно добавить колонки, изменить ограничения и т.д.

Серж Например, в таблицу "траспорт" добавить поле "тип транспорта". А это уже денормализация. И надо будет учитывать недостатки данного решения.

Jelis могу привести пример с отношением многие-ко-многим: тут без вопросов решаеться путём введения допонительной таблицы, и особо раздумывать не надо!Задавшись целью, можно будет скроить начальные условия при которых "многие-ко-многим" оптимально будет решать без дополнительной таблицы.

IMHO цель форума - для каждого решения найти достоинства и недостатки, которые дизайнер должен взвесить и принять вольюнтаристкое решение
(мы посовещались и я решил)
...
Рейтинг: 0 / 0
03.12.2009, 17:58
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346842
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
SERG1257Задавшись целью, можно будет скроить начальные условия при которых "многие-ко-многим" оптимально будет решать без дополнительной таблицы.это как?
...
Рейтинг: 0 / 0
03.12.2009, 18:21
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346891
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
egorych это как?
Через ж..у
...
Рейтинг: 0 / 0
03.12.2009, 18:37
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346941
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
Серж
И вторая отправная точка для размышлений - как вы будете определять что конкретный транспорт "грузовой" или "легковой"? Если if exists(select * from "грузовой") then "грузовой" else "легковой"... А если по другому? Например, в таблицу "траспорт" добавить поле "тип транспорта".

Ну да, с определением типа в такой схеме есть сложность. Я обычно с начала в запросах где надо занть тип делаю что то такое :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
  -- весь кейс можно в хранимку засунуть, тогда выглядит читабелнее
  CASE WHEN легковой_id IS NOT NULL THEN 'легковой'
          WHEN грузовой_id IS NOT NULL THEN 'грузовой'
          ELSE 'wtf?' -- или NULL, или ексепшен генерить
   END AS тип_транспорта
FROM Транспорт
LEFT OUTER JOIN Легковой
LEFT OUTRE JOIN Грузовой

А потом, когда либо выяснение типа расплываеться по многим местам или приходиться уже обращать внимание на производительность, делаю таки поле тип_транспорта в таблице Транспорт и заполняю его из триггеров.
Вообщем, определение типа можно смело записывать в недостатки первого варианта, во втором чуть по проще.
...
Рейтинг: 0 / 0
03.12.2009, 18:58
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36346958
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jelis
Гость
NafЯ за первый вариант, как раз НЕЧТО такое реализую, но у меня в дочерней таблице ParentID=ID, то есть первичный ключ дочерней таблицы является одновременно внешним к родительской.
Да, иногда получаеться сделать сквозные идишники, иногда нет. Кстати, может кто-нибудь расскажет о подводных камнях со сквозными идишниками в первой схеме? Что-то я даже впомнить не могу ни каких грабель на эту тему.
Naf
Кроме того для каждой дочерней таблицы постороена VIEW по типу:
Код: plaintext
1.
2.
SELECT ChildTable.ID,ChildTable....,ParentTable....
FROM ChildTable
INNER JOIN ParentTable ON (ChildTable.ID=ParentTable.ID)
и навешены триггеры к нему, так что можно оперировать этой VIEW как единым объектом
С уважением, Naf
Триггеры вешаються прямо на вьюху? А что за СУБД, можно узнать?
...
Рейтинг: 0 / 0
03.12.2009, 19:08
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36347063
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
П-Л
Участник
instead of trigger
...
Рейтинг: 0 / 0
03.12.2009, 20:20
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36347392
Серж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серж
Участник
SERG1257А это уже денормализация. И надо будет учитывать недостатки данного решения.Денормализировать, как правило, все равно приходится. Если применять ее осмысленно, то ничего страшного в этом нет.

JelisВообщем, определение типа можно смело записывать в недостатки первого варианта, во втором чуть по проще.Да тот же самый case when легковой_Id is not null then 'легковой'...

Jelis
Код: plaintext
1.
2.
LEFT OUTER JOIN Легковой
LEFT OUTRE JOIN Грузовой

А где на практике такой запрос применяется? Т.е. какой смысл одновременно вязать две таблицы с совершенно разными данными, одна из которых гарантированна будет пустой.

Jelis
Кстати, может кто-нибудь расскажет о подводных камнях со сквозными идишниками в первой схеме? ...Что-то упустил сразу этот момент... Я считаю что ИД транспорта это ФК в таблицах легковой, грузовой и одновременно ПК. Т.е. значение ИД одно. Это понимается под сквозными ИД? Я делал именно так и никаких подводных камней не нашел. А в случае с гуидами, вообще все ИД по базе сквозные.
...
Рейтинг: 0 / 0
04.12.2009, 05:27
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36347550
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
JelisТриггеры вешаються прямо на вьюху? А что за СУБД, можно узнать? Firebird, MS SQL Server
...
Рейтинг: 0 / 0
04.12.2009, 09:19
| Ответить | Цитировать | Написать  
Поддержка уникальности в таблицах, расширяющих родительскую.
    #36347552
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
Забыл уточнить, у родительской таблицы еще есть поле - идентификатор вида конечной дочерней таблицы - число мнемоническое, у меня. Чтобы по записи в родительской можно было понять кокретный "тип" записи не устраивая соединений с дочерними
С уважением, Naf
...
Рейтинг: 0 / 0
04.12.2009, 09:21
| Ответить | Цитировать | Написать  
23 сообщений из 23, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Поддержка уникальности в таблицах, расширяющих родительскую.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=80&tid=1542950]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 65ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 75ms
get tp. blocked users:
 2ms
others: 245ms
total:  437ms
созд. / загр.: 437ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]