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

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 

У вас есть несколько вариантов решения этой проблемы «сущности».

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

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

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

4. Используйте дополнительные поля FK в базе данных. Для этого требуется объединение между базой данных, объединенной с Cluster plus Database, соединенной с сервером, чтобы получить полный список баз данных. Каждая База данных должна иметь дискриминатор, чтобы вы могли различать различные комбинации значений NULL в двух FK-полях. Существует четыре возможных сочетания, из которых два разумны, а два могут быть запрещены. Попытка просто использовать два нулевых FK обычно не работает хорошо, поэтому вам часто нужен флаг состояния для разделения базы данных на кластере из базы данных на сервере из базы данных, не привязанной ни к чему, от базы данных с неизвестным хостингом из любого другого состояния, которое может быть Соответствующий.

Answer 2

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

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

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