Было бы неплохо представить общую модель данных или, по крайней мере, систему общих типов в вашей модели данных. Концепция состоит в том, что у всего есть запись, даже действия, люди, страницы, процессы и так далее. Когда это происходит, вам нужен общий способ создания произвольных отношений между этими объектами, что делает его связывание между ними довольно простым. Ваш вопрос является одним из примеров того, почему я продвигаю более общую модель данных, а не супернормализованную модель, которую мы обычно используем.
Модель, которую я использую чаще всего, - Тематические карты (хотя эта информация может быть не самой простой в использовании, чтобы понять, о чем я говорю), где вместо таблицы для каждой сущности, есть один, который содержит все, и несколько дополнительных, чтобы иметь дело с типизацией и отношениями между ними. Вам не нужно идти с этим до конца, но, возможно, используйте его специально для вашего случая использования. Вот статья, которую я написал об этом почти 10 лет назад, и еще одна статья Марка де Грауу , в которой также рассматривается конкретный взгляд на СУБД.
Вернуться к вашему вопросу. Для примера использования тематических карт сначала нужны таблицы;
Topic
-----
id
name
type
meta_date_created
meta_date_created_topic_ref
meta_date_updated
meta_date_updated_topic_ref
meta_date_deleted
meta_date_deleted_topic_ref
Assoc (relationship)
--------------------
id
type
Assoc member
------------
id
topic_ref
role_topic_ref
Это даст вам основы (но есть множество вещей, которые можно расширять и реализовывать, если вы хотите работать полностью, например, поддержка нескольких типов, постоянная идентификация, группировка онтологий, и так далее, которая также является частью тематических карт). ) и предоставит вам поля meta_ * в виде удобных ярлыков, если это действительно все, что вам нужно (они хороши для быстрого поиска:).
Каждый человек будет иметь запись в «Теме», пример;
id: 4572349857
name: Alexander Johannesen
type: 12341234
meta_date_create: {date}
meta_date_create_topic_ref: 5656
Чтобы узнать, кто создал этого пользователя, поищите в «Теме» идентификатор «5656»;
id: 5656
name: Billy Bob
type: 12341234
Но что это за тип? Ищите в «Теме» идентификатор «12341234»;
id: 12341234
name: Person
Концептуальная основа здесь заключается в том, что каждая «вещь» (намеренно неопределенная; это может быть все, о чем вы хотите поговорить) в вашей системе получает запись, включая действия;
id: 34598067
name: Add new user
type: 56987 // another topic called 'Action', for example)
При всем этом ваш журнал в основном создает отношения между этими сущностями через таблицу «Assoc»;
id: 45673
type: 45685678
Это сама ассоциация. Идентификатор - это что угодно, не важно, но тип - это (как вы уже догадались) другая сущность в таблице «Тема»;
id: 45685678
name: Did action
Теперь вы заполняете таблицу 'Assoc member' с подробной информацией о регистрации действия;
id: {whatever}
topic_ref: 5656
role_topic_ref: 12341234
Первый участник - Билли Боб, который играет роль «Персона». Далее;
id: {whatever}
topic_ref: 34598067
role_topic_ref: 56987
Здесь тема «Добавить нового пользователя» играет роль «Действие». Вы можете расширить эту связь, добавив столько элементов, сколько вам нужно, например, добавление в предварительном состоянии, результат действия, количество попыток до сих пор, где выполнялось действие (например, если это функция, которую могут выполнять люди. количество страниц), и так далее. Создайте сущности для этих вещей в таблице Темы, создайте сущности для их отношений, и вы можете сделать это настолько сложным, насколько захотите.
Поначалу все это может показаться немного странным, но оно невероятно гибкое, и вам совсем не нужно менять свою модель данных для будущих расширений. Я строил системы, используя эту модель в течение многих лет, и у меня есть только похвала за это. Отдельная таблица свойств темы будет следовать модели для членов ассоциации, если вы хотите пойти по этому пути.
Возможно, можно было бы обосновать производительность меньшего количества таблиц, подобных этой, но по моему опыту большинство СУБД прекрасно работают с внутренними объединениями, которые являются основным инструментом, необходимым для выполнения этой работы (все поля, которые являются идентификаторами, являются очевидными кандидатами в индексы). ), и хорошо то, что это также в основном совместимо с средствами мышления NoSQL, создавая достаточную абстракцию между вами и вашими данными, а также SQL и технической механикой, которую хочет использовать серверная часть.