Лучший способ реализовать таблицу Notes для многих сущностей Таблицы в SQL

Question

У меня есть много таблиц: клиенты, потенциальные клиенты, друзья ..
У них у всех есть несколько Заметок.

Вопрос 1. Должен ли я иметь одну Таблицу заметок, которая будет использоваться совместно со всеми родительскими таблицами.
Должны ли я иметь таблицы NotesCustomer, NotesProspect, NotesFriends?

Вопрос 2:
Если лучшим решением является первое, тогда эта общая таблица Notes должна иметь FK для родительской таблицы, но ТАКЖЕ тип родительской таблицы?

Я использую EntityFramework, но этот вопрос также общий, я думаю ...

Спасибо, Джон

Answer 1

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

Если вы используете таблицу общих примечаний, вам потребуется три столбца FK, которые можно обнулятьк какой связанной таблице принадлежит FK, и только одна из них заполняется в каждой строке.

Вообще говоря, цель хорошей реляционной модели - НЕ (или не обязательно) хранить подобные данные вместе, а толькосохранить конкретные данные один раз.Таким образом, хороший вопрос, который нужно задать себе при разработке, это «что я получаю, храня все заметки в одной таблице?»

Answer 2

лучший вариант - одна таблица Notes, используемая совместно со всеми остальными.

вы можете использовать два поля notes_obj_id и notes_obj_type для реализации общих заметок таблицы Notes

Answer 3

Я понимаю, что это старый, но ..

Это позволит использовать более одной заметки.

select n.NoteId, n.NotesDetail from Prospect p inner join Notes n 
on n.EntityId = p.id AND n.EntityType ='prospect'

Answer 4

У вас должна быть только одна таблица заметок.Отношение переходит от Notes к другим объектам (это 0: M), поэтому нет необходимости иметь столбцы FK на уровне таблицы Notes.Столбцы FK для Prospect, Customer, Friend, в таблице Notes приводят только к дизайну, в котором вам нужно будет продолжать добавлять столбцы FK в таблицу Notes каждый раз, когда новый объект нуждается в Notes (и это на самом деле не ускоряет процесс),

Например, если вы хотите получить список всех заметок Prospect, просто запросите таблицу Prospect и используйте объединение, если вам нужно получить детализацию заметок:

select n.NoteId, n.NotesDetail from Prospect p inner join Notes n 
    on p.NoteId = n.NoteId

Ваша таблица Notes можетвыглядит примерно так:

create table Notes
(
    NoteId int identity(1,1)
    ,NotesDetail varchar(max)
    // ... any other fields related to the Notes entity....
)

В других таблицах все, что вам нужно, это поле FK, связывающее NoteId в таблице Notes.

Answer 5

Я бы интуитивно предпочел подход с одним столом, но у него есть и свои недостатки.Pro one-table: создание нескольких таблиц с одинаковой структурой может быть проблематичным, если вам когда-либо потребуется изменить их структуру.Кроме того, вам придется вводить переменную для имени таблицы всякий раз, когда вы запрашиваете примечания, вместо логически более чистого параметра типа.Однако аргументы Фила тоже интересны.Вы также можете обнаружить, что макет с одной таблицей может привести к созданию базы данных, к которой больше нельзя обращаться с помощью простого SQL.Если у вас будет много данных, то наличие разных таблиц также даст вам разницу в скорости.

Hm.Действительно чистым, но и несколько сложным решением было бы создать таблицу NotableObject.Затем укажите каждому клиенту, потенциальному клиенту, независимо от поля «NotableObjectID», и свяжите примечания с NotableObjects, а не с клиентами или потенциальным клиентом.Конечно, это усложняет ситуацию, если вы хотите что-то вроде «Дайте мне все заметки о клиентах», потому что вы явно храните только информацию от клиентов, чтобы делать заметки, а не наоборот, но, поскольку, в большинстве случаев, вы будете иметь ситуацию, похожую на «дайте мне все заметки для этого клиента ", вы можете быть в порядке.