[Проектирование БД, практика] Сущности с набором общих свойств?
Все проще.
Идут по второму пути, но не ставят никаких ссылок.
Просто у клиента должен быть уникальный идентификатор и признак физик/юрик.
По этому признаку определяется, в какой таблице искать доп. инфо.
А связь таблиц осуществляется по ID клиента.
Кстати, этот вариант легко расширяется в случае появления других типов клиентов, например - банки или ИП.
Идут по второму пути, но не ставят никаких ссылок.
Просто у клиента должен быть уникальный идентификатор и признак физик/юрик.
По этому признаку определяется, в какой таблице искать доп. инфо.
А связь таблиц осуществляется по ID клиента.
Кстати, этот вариант легко расширяется в случае появления других типов клиентов, например - банки или ИП.
Кстати, этот вариант легко расширяется в случае появления других типов клиентов, например - банки или ИП.я так понимаю ты про третий вариант говоришь
Спасибо
Есть аргументация, почему так?
Есть аргументация, почему так?
Да, не обратил внимания.
Это действительно третий вариант.
На практике удобство заключается в том, что эта схема очень гибкая.
Весь софт в банке заточен на то, что таблица с доп. инфо может измениться в любой момент.
И на самом деле, при изменении требований бизнеса доп. инфо меняется довольно часто.
Если закладываться на одну таблицу, придется регулярно менять именно ее.
З.Ы. Но если структура доп. инфо не очень длинная, и ее не предполагается менять, то я встречал и вариант 2.
Это действительно третий вариант.
Есть аргументация, почему так?Я этой аргументации не знаю, но неоднократно встречал применение этого подхода в реальной АБС.
На практике удобство заключается в том, что эта схема очень гибкая.
Весь софт в банке заточен на то, что таблица с доп. инфо может измениться в любой момент.
И на самом деле, при изменении требований бизнеса доп. инфо меняется довольно часто.
Если закладываться на одну таблицу, придется регулярно менять именно ее.
З.Ы. Но если структура доп. инфо не очень длинная, и ее не предполагается менять, то я встречал и вариант 2.
+1 за третий вариант в том изложении, что описано эдвардом.
Это, фактически, наследование
Это, фактически, наследование
Ты описал 3 из 4, по-моему, вариантов классического способа реализации наследования в реляционных СУБД.
Пользоваться надо тем, который удобнее в твоей конкретной задаче.
А еще, если у тебя, например, постгре, то в нем есть встроенное наследование на уровне СУБД, так что там можно не заморачиваться.
Пользоваться надо тем, который удобнее в твоей конкретной задаче.
А еще, если у тебя, например, постгре, то в нем есть встроенное наследование на уровне СУБД, так что там можно не заморачиваться.
Как я понимаю, обычно идут по второму пути.Обычно поступают в соответствии с приоритетами, в литературе давно описаны преимущества и недостатки каждого варианта. Например, сильно зависит от того, какие типичные запросы будут выполняться в системе.
Оставить комментарий
Realist
Добрый!Я пишу базу клиентов некой конторы. Реляционную. Клиенты могут быть физическими лицами, могут быть юридическими. Для обоих есть общие свойства и ссылки (адрес, телефон, история заказов). Но у частников есть фамилия, имя, день рождения, а у контор есть форма собственности и адрес сайта в интернете. Как на практике правильней организовать такое:
1. Две разные таблицы для частников и контор. Очевидно, решение не рулит.
2. Пихать все в одну таблицу, для контор одни поля оставлять пустыми, для частников — другие
3. В таблице "клиенты" сделать ссылку на таблицу "доп инфо о частниках" и ссылку на "доп инфо для контор". У одних заполнять одну ссылку, у других — другую.
Как я понимаю, обычно идут по второму пути.
Спасибо