Записи связаны с какой-либо таблицей?

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

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

Чтобы обеспечить целостность данных, вы можете создать набор триггеров или какое-либо программное решение, которое будет время от времени очищать таблицу заметок.

1144551]

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

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

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

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

Я бы дважды подумал, прежде чем сделать то, что вы предлагаете. В краткосрочной перспективе это может показаться простым и элегантным, но если вы действительно заинтересованы в целостности и производительности данных, то лучше всего иметь отдельные таблицы заметок для каждой родительской таблицы. На протяжении многих лет я подходил к этой проблеме, используя решения, найденные в других ответах (триггеры, идентификаторы GUID и т. Д.). Я пришел к выводу, что дополнительная сложность и потеря производительности того не стоят. Имея отдельные таблицы примечаний для каждой родительской таблицы с соответствующими ограничениями внешнего ключа, поиск и объединение будут простыми и быстрыми. При объединении связанных элементов в одну таблицу синтаксис объединения становится некрасивым, и ваша таблица заметок станет огромной и медленной.

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

create table Notes (
    id int PRIMARY KEY,
    note varchar (whatever),
    customer_id int NULL REFERENCES Customer (id),
    product_id int NULL REFERENCES Product (id)
)

Тогда вам понадобится ограничение, чтобы убедиться, что у вас есть установлен только один столбец.

Или, может быть, вы хотите, чтобы заметку можно было связать и с покупателем, и с продуктом. На ваше усмотрение.

Этот дизайн потребует добавления нового столбца в Notes, если вы хотите добавить еще одну справочную таблицу.

Я в некоторой степени согласен с Майклом Маклоски.

У меня возникает вопрос: какова техническая стоимость наличия нескольких таблиц заметок?

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

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

Чтобы ответить на ваш вопрос ...

Вариант, который я бы использовал, - это проверка ограничения с использованием функции, определяемой пользователем, для проверки значений. Это работает в M $ SQL Server ...

CREATE TABLE Test_Table_1 (id INT IDENTITY(1,1), val INT)
GO
CREATE TABLE Test_Table_2 (id INT IDENTITY(1,1), val INT)
GO
CREATE TABLE Test_Table_3 (fk_id INT, table_name VARCHAR(64))
GO

CREATE FUNCTION id_exists (@id INT, @table_name VARCHAR(64))
RETURNS INT
AS
BEGIN
    IF (@table_name = 'Test_Table_1')
        IF EXISTS(SELECT * FROM Test_Table_1 WHERE id = @id)
            RETURN 1
    ELSE
    IF (@table_name = 'Test_Table_2')
        IF EXISTS(SELECT * FROM Test_Table_2 WHERE id = @id)
            RETURN 1

    RETURN 0
END
GO

ALTER TABLE Test_Table_3 WITH CHECK ADD CONSTRAINT
    CK_Test_Table_3 CHECK ((dbo.id_exists(fk_id,table_name)=(1)))
GO
ALTER TABLE [dbo].[Test_Table_3] CHECK CONSTRAINT [CK_Test_Table_3]
GO

INSERT INTO Test_Table_1 SELECT 1
GO
INSERT INTO Test_Table_1 SELECT 2
GO
INSERT INTO Test_Table_1 SELECT 3
GO
INSERT INTO Test_Table_2 SELECT 1
GO
INSERT INTO Test_Table_2 SELECT 2
GO
INSERT INTO Test_Table_3 SELECT 3, 'Test_Table_1'
GO
INSERT INTO Test_Table_3 SELECT 3, 'Test_Table_2'
GO

В этом примере последняя инструкция вставки завершится ошибкой.

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

Почему бы вам не сделать это наоборот и не использовать внешний ключ в других таблицах ( Заказчик, поставщик и т. Д.) В NotesID. Таким образом, у вас есть однозначное сопоставление.

Вы можете добавить поле GUID в таблицы «Клиенты», «Поставщики» и т. Д. Затем в таблице Notes измените внешний ключ, чтобы он ссылался на этот GUID.

Это не помогает для целостности данных. Но это делает возможными отношения M-to-N для любого количества таблиц и избавляет вас от необходимости определять столбец NoteFKType в таблице Notes.