простой вопрос разработки БД

Question

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

У меня есть следующие таблицы:

Клиент, Компания, Метр, Чтение

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

Я вижу здесь два решения:

1.) Использовать отношения m: n: CustomerComment, CompanyComment и т. Д. -> позже легко расширять, но много новых таблиц 2.) используйте отношения 1: n: в таблице комментариев есть поле для PK таблиц выше (Customer_id, Company_id, ...) -> минимальный подход к таблице, но «сложнее» расширить, так как мне пришлось бы добавить новый поле для таблицы комментариев всякий раз, когда появляется новая таблица, которая должна иметь комментарии

Цель - это модульное приложение, которое может иметь или не иметь ни одну из этих четырех таблиц.

Какой из них лучше - или их больше?

Спасибо!

Answer 1

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

Истинный уникальный идентификатор для любой данной строки для Клиента, Компании, Метра, Чтения является UUID. Может быть, из-за структуры базы данных первичный ключ должен быть целым числом, но это нормально. Это означает, что вам никогда не нужно добавлять поля в таблицу COMMENTS, если у вас есть новый тип в вашей системе. Он всегда будет ссылаться на типы ID.

Ваши таблицы могут выглядеть так:

CUSTOMER
   ID UUID

COMPANY
   ID UUID

METER
   ID UUID

COMMENTS
   ID
   RELATED_TO UUID
   COMMENT TEXT

Теперь вы можете прикреплять комментарии к любой таблице с уникальным идентификатором.

Если вы хотите поддерживать ссылочные ограничения

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

OBJECT
   ID UUID 

CUSTOMER
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

COMPANY
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

METER
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

COMMENTS
   ID
   RELATED_TO UUID
   COMMENT TEXT
   FOREIGN_KEY (RELATED_TO) REFERENCES OBJECT(ID) ON DELETE CASCADE

Это усложняет конструкцию, чтобы гарантировать, что вам не нужно добавлять 2 таблицы для каждого нового типа в системе. У каждого дизайна есть свои жертвы. В этой статье вы усложняете задачу, говоря для каждой записи, будь то Компания, Клиент, Метр. Мне нужен связанный идентификатор в таблице объектов, чтобы я мог добавить внешний ключ.

Answer 2

Я предпочитаю по одному для каждой пары - CustomerComment, CompanyComment и т. Д. Это в конечном итоге ускорит ваши запросы, и, хотя оно не так «расширяемо», как одна таблица CommentLink, вам потребуется вносить изменения в схему, когда выдобавьте что-то еще, что в любом случае нуждается в комментариях.

Answer 3

Я бы использовал отдельные таблицы, чтобы вы могли сохранить ссылочные ограничения простыми.