Динамическая система уведомлений - это кажется странным кому-то еще, кроме меня?

Question

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

Уведомления

id
notification_type_id
data
created_at

Уведомления пользователей

user_id
notification_id
is_read

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

Пример: {post_id: 123, user_id: 456} создаст сообщение "Дамбо ответил на ваш вопрос Сколько это стоит ...?"

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

Answer 1

Реляционная модель допускает произвольно сложные типы.Но если сложный тип имеет некоторую внутреннюю структуру, то

• дБмс игнорирует его или
• дБмс (не пользователь) предоставляет функции для управления им.

Даты, например, имеют внутреннюю структуру.Системы управления базами данных предоставляют функции для управления этой структурой путем ее усечения, извлечения ее частей, добавления и вычитания интервалов и т. Д.

JSON также имеет внутреннюю структуру.Если ваша СУБД поддерживает тип данных JSON, она предоставит функции для управления им.Если это не так, он игнорирует тот факт, что это тип JSON, и просто возвращает сохраненные данные JSON пользователю.

Пока проблем нет.

Но, сказав, что,,.

Пример: {post_id: 123, user_id: 456} создаст сообщение "Дамбо ответил на ваш вопрос Сколько это стоит ...?"

Одна проблема здесь заключается в том, что dbms не может гарантировать, что user_id 456 существует, поэтому вызывающая сторона не может знать, будет ли работать преобразование из идентификационного номера в имя.Он также не может знать, существует ли еще идентификатор сообщения 123.Эти виды ограничений предназначены для внешних ключей, и вы не можете применять ограничения внешнего ключа для идентификаторов, хранящихся в формате JSON.

Ваш основной риск - возвращение глупости (или NULL) вызывающей стороне.В некоторых случаях это совершенно оправданно.(Блоги, например. Кому действительно важно, если вы время от времени получаете бессмысленное сообщение?) В других случаях это может быть катастрофическим.

Если вместо этого вы сохраните текст «Дамбо ответил на ваш вопрос:« Сколько ... »», то не будет никаких шансов на неудачу из-за удаленных пользователей или сообщений.Даже если пост и пользователь были удалены, сообщение «Дамбо ответил на ваш вопрос:« Сколько ... »» все равно будет истинным фактом.(Хотя, возможно, несколько менее полезно, в зависимости от того, как ваша система обрабатывает удаления.)

Answer 2

Да, странно, если вам нужна нормализованная база данных.Если у сущности A есть зависимость от сущности B, вы ДО вставьте внешний ключ в A.Пара зависимостей - одинаковое количество ключей.Я вижу проблему в вашем случае в другой структуре для сущности Notifications в зависимости от некоторого notification_type.Это означает, что вы получили наследование в базах данных .Есть несколько стратегий, которые позволяют вам создать правильную архитектуру для ваших нужд.Попробуйте это для сравнения.

Надеюсь, я правильно понял проблему.