#sql-server #tsql #database-design #schema #social-networking
#sql-server #tsql #база данных-дизайн #схема #социальные сети
Вопрос:
Я разрабатываю то, что по сути является бухгалтерским / розничным приложением для MS SQL Server 2016. У меня ~ 75 основных типов объектов данных, каждый в своей соответствующей таблице (пользователи, организации, счета-фактуры, платежи и т.д.).
Что мне нужно создать, так это систему уведомлений,
например, «Стив оплатил счет 1234», «Боб приобрел продукт XYZ» и т. Д. Я собирался создать таблицу «типы уведомлений»:
NotificationTypes:
id message
11 "{0} paid invoice {1]"
12 "{0} purchased product {1]"
...
а затем иметь две соответствующие таблицы, в которых хранится информация о каждом событии уведомления, а затем значения для этого сообщения уведомления. Так, например, для «Steve оплатил счет-фактуру 1234»:
NotificationEvent:
id notificationType (FK) occured
21 11 2016-01-01 00:00:00
NotificationEventValues:
id notificationEvent (FK) XXXXX
31 21 (FK reference to Steve in users table)
32 21 (FK reference to invoice 1234 in invoices table)
Теперь, поскольку я не могу создать общие внешние ключи для NotificationEventValues.XXXXX, я собирался создать единую таблицу «DataObjects», в которой есть столбцы FK для всех 75 типов данных, которые у меня есть, и только один из столбцов «тип данных» имеет значение для каждой строки.
Таким образом, каждый экземпляр объекта данных в моей базе данных имеет уникальный идентификатор, на который я могу ссылаться в поле уведомления, что будет означать огромную таблицу, учитывая, что она имеет уникальный идентификатор практически для каждой строки в других 75 таблицах. Другим недостатком является то, что это означает, что для каждого пользователя, счета-фактуры, любого «объекта данных» я трачу значительное количество места, поскольку пространство будет зарезервировано для ссылок на идентификаторы для остальных 74 столбцов с нулевым значением (поскольку они являются идентификаторами фиксированного размера, а не переменными).
СПРОСИТЕ:
Есть ли лучший способ получить мой «глобальный» идентификатор во всех таблицах? Или лучший способ обработки системы уведомлений, чтобы избежать этой проблемы?
Комментарии:
1. Не используйте глобальные идентификаторы. Мы сделали это в одном из наших крупных проектов и хотели бы, чтобы мы этого не делали.
2. Что вы использовали вместо этого, чтобы обойти это?
3. Вы не можете просто изменить большую систему. Но вам действительно нужно, чтобы числа были уникальными для всей базы данных?
Ответ №1:
Создайте триггеры во всей таблице, которые будут вставлять запись в таблицу, скажем, KeyMaster, с одним ключом столбца, который также будет основным ключом всякий раз, когда запись вставляется в любую таблицу. Значение, вставленное в эту таблицу, будет иметь формат _. Например, если в таблицу user вставлена запись с идентификатором 1, то запись, вставленная в таблицу KeyMaster, будет «user_1». Аналогично, если в таблицу счетов-фактур вставлена запись с идентификатором 1, то запись, вставленная в таблицу ключей, будет «invoice_1».
В вашей таблице NotificationEventValues вам понадобятся только три столбца id, NotificationEvent и key (ссылка FK на таблицу KeyMaster).
Для получения соответствующей записи вам необходимо написать запрос, аналогичный приведенному ниже:
select *
from NotificationEventValues n
inner join users u on 'user_' u.id = n.key