Проблема проектирования базы данных

Question

Я пытаюсь спроектировать базу данных для сервера и инвентаризации баз данных, и я ищу хороший дизайн базы данных.У нас есть таблицы для кластеров серверов, автономных серверов и баз данных.Я хотел бы представить следующие отношения в базе данных:

Отношение "один ко многим" от кластера к серверам.
Отношение "один ко многим" от базы данных к кластеру / серверу.

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

Answer 1

Похоже, что у вас есть это в вашем реляционном взгляде на ситуацию.

Cluster : name, other attributes of cluster

Server : name, optional FK to cluster, other attributes of a server

Database : name, (FK to cluster OR FK to server)

Проблема в том, что у вас несколько более сложная ситуация в реальном мире, которую технология отношений не отражает в полной мере.

Host -- an abstract superclass for places a database can run.

Cluster (extends Host) : name, etc.

Server (extends Host) : name, optional FK to cluster.

Database : FK to Host

У вас есть несколько вариантов решения проблемы такого рода "subentity".

1. Сверните хост, Кластер и Сервер в единую таблицу.Это приводит к рекурсивной взаимосвязи между Хостом (как кластером) и Хостом (как сервером).Это немного раздражает, но это создает единую таблицу для хоста, кластера и Сервера.Результирующая таблица содержит много нулей (строки кластера используют одну группу столбцов, строки сервера используют другой набор столбцов.) Вам нужно добавить столбец, чтобы различать подразделы Host.

2. Передайте информацию о хосте в кластер и на сервер.Это полезно, когда у вас много общей информации в таблице Host и очень мало информации, относящейся к подклассу, в таблицах кластера или Сервера.Таблицы кластера и Сервера выглядят очень похожими (по сути, клоны хоста) с несколькими отличающимися столбцами.

3. Используйте соединение между (хостом и кластером) или (хостом и сервером) на основе дискриминатора в Host.Несмотря на то, что это довольно сложно, это хорошо масштабируется, потому что все базы данных присоединены к Хосту, а полный список Хостов представляет собой объединение Хостов, которые присоединяются к Серверу, плюс хостов, которые присоединяются к кластеру.

4. Используйте необязательные поля FK в базе данных.Для этого требуется объединение базы данных, присоединенной к кластеру, плюс базы данных, присоединенной к Серверу, чтобы получить полный список баз данных.Возможно, в каждой базе данных должен быть дискриминатор, чтобы вы могли различать различные комбинации нулевых значений в двух полях FK.Существует четыре возможных комбинации, из которых две являются разумными, а две могут быть запрещены.Попытка просто использовать два nullable FK обычно не срабатывает, поэтому вам часто нужен флаг статуса, чтобы отделить базу данных в кластере от базы данных на сервере, от базы данных, которой ничего не назначено, от базы данных с неизвестным хостингом, от любого другого статуса, который может иметь значение.

Answer 2

Вариант 1:Имейте два поля в таблице базы данных.Один относится к серверу, другой - к кластеру.Оставьте один из них нулевым.

Вариант 2:Другой подход заключается в добавлении записи в кластер также для каждого отдельного сервера и ссылки только на эту таблицу.

Вариант 1 действительно не самое чистое решение (я согласен с комментариями), поэтому выбирайте вариант 2 :)