Отдельные таблицы на верстаке sql, а не одна

У меня наверное банальный вопрос, но нужен совет.

Я работаю в СУБД центра, где есть два разных типа клиентов: назовем их клиентОбычный и клиентСпециальный.

Конечно, у них есть общие атрибуты, такие как имя, фамилия, дата рождения ... И тогда клиентСпециальный имеет атрибуты, которых нет у клиентОбычный и наоборот.

Затем customerSpecial и customerOrdinary подключаются к разным таблицам: клиентОбычный подключается к table1, а клиентСпециальный подключается к table2 и table3.

На данный момент, зная это, у меня есть 2 возможных способа:

СПОСОБ 1:

создайте единую таблицу «customer» со всеми общими атрибутами, а затем две другие таблицы customerS и customerO с тем же PK и другими столбцами.

CUSTOMER
ID     DATEOFBIRTH.  NAME.   SURNAME.   TYPE
01.    1989/07/12.   Sal.     Dallow.    S
02.    1987/09/12.   Kreb.    Krusty.    O
03.    1999/01/02.   Josh.    Milly.     S

CustomerO
ID.      NumberOfCr.   .....
02.       18273.       .....

Customer S
ID.     DateAsmp.    DateEnd.     TypeCon
01.     2020/12/12.  2021/10/07.    STN
03.     2020/11/22.  2020/12/30.    PLS

ПУТЬ 2

Создайте сразу 2 разные и отдельные таблицы, CustomerO и CustomerS:

CustomerS 
ID     DATEOFBIRTH.  NAME.   SURNAME.  DateAsmp.    DateEnd.     TypeCon 
01.    1989/07/12.   Sal.     Dallow.  2020/12/12.  2021/10/07.    STN
03.    1999/01/02.   Josh.    Milly.   2020/11/22.  2020/12/30.    PLS


CustomerO
ID     DATEOFBIRTH.  NAME.   SURNAME.   NumberOfCr.  
02.    1987/09/12.   Kreb.    Krusty.   18273.

Как вы думаете, какой подход мне следует придерживаться? Зачем? И самое главное, первый подход в чем-то неверен?

два разных типа клиентов Это говорит вам, что именно вам нужно / нужно поддерживать.
SMor 09.04.2021 18:16

@SMor, а какой, по-твоему, лучше?

Jenny 09.04.2021 18:17

Я удалил sql-сервер, поскольку он конфликтовал с MySQL, а SQL Workbench - это среда разработки MySQL, а не SQL Server.

Larnu 09.04.2021 18:18
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для разработчиков
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для разработчиков
В последние годы архитектура микросервисов приобрела популярность как способ построения масштабируемых и гибких приложений. Laravel , популярный PHP...
Как построить CRUD-приложение в Laravel
Как построить CRUD-приложение в Laravel
Laravel - это популярный PHP-фреймворк, который позволяет быстро и легко создавать веб-приложения. Одной из наиболее распространенных задач в...
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
В предыдущем посте мы создали функциональность вставки и чтения для нашей динамической СУБД. В этом посте мы собираемся реализовать функции обновления...
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
Роли и разрешения пользователей без пакета Laravel 9
Роли и разрешения пользователей без пакета Laravel 9
Этот пост изначально был опубликован на techsolutionstuff.com .
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
0
3
25
1

Ответы 1

Вопрос зависит от того, нужны ли вам отношения внешнего ключа с «клиентом». И я предполагаю, что ответ - «да».

Это говорит о том, что первый подход лучше. Если вам не нужны отношения внешнего ключа для «обычных» и «специальных» клиентов, вы можете рассмотреть возможность хранения всех столбцов в одной таблице и не беспокоиться о значениях NULL.

Да, внешний ключ «CustomerO_ID» используется в двух таблицах (таблица 1 и таблица 2); в то время как внешний ключ «CustomerS_ID» используется в другой таблице (таблица 3). Вместо этого "CustomerID" fk никогда не используется в других таблицах. (Первый подход)

Jenny 09.04.2021 18:10

Нет никакой связи между таблицей и «клиентом» в целом, включая как тип S, так и тип O. Все отношения устанавливаются отдельно, либо с CustomerS, либо с customerO.

Jenny 09.04.2021 18:11

@ Дженни. . . Я подозреваю, что в вашей системе вам понадобятся связи между таблицами и customers в целом - транзакции, контракты или что-то в этом роде.

Gordon Linoff 09.04.2021 18:13

Нет, считайте, что «заказчик» - это просто пример, который я сообщил, чтобы упростить и обобщить мою проблему. так фейк, что мне не нужны отношения между таблицами и покупателем в целом

Jenny 09.04.2021 18:15

Другие вопросы по теме