Предложение схемы базы данных для сайта, управляемого виджетами

Question

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

Для начала мой сайт на самом деле состоит из виджетов. Для каждого виджета мне нужна таблица для settings (где каждый экземпляр виджета имеет свои пользовательские настройки), таблица для common (общие элементы между экземплярами одного и того же виджета) и userdata (пользовательские сохраненные данные внутри экземпляра виджета).

До сих пор у меня была следующая схема, состоящая из 2 баз данных:

• первая база данных, где у меня были все таблицы обслуживания сайта (например, пользователи, установленные виджеты, журналы, уведомления, сообщения и т. Д.), А также таблица, в которой я присоединял каждый экземпляр виджета к каждому пользователю, который его создал, назначив уникальный ID (поэтому у меня есть следующие столбцы: user_id, widget_id и unique_id).
• вторая база данных, где я хранил все данные, связанные с виджетами. Это означает, что для каждого виджета (уникального по widget_id) у меня было три таблицы: [widget_id]_settings, [widget_id]_common и [widget_id]_userdata. В каждой из этих таблиц каждая строка содержала unique_id виджета пользователя. На самом деле здесь были все данные пользователей, хранящиеся в виджете.

Чтобы дать краткий пример того, как работают мои базы данных:

Первая база данных:

• В таблице users у меня есть user_id = 1
• В таблице widgets у меня есть widget_id = 1
• В таблице users_widgets у меня есть user_id = 1, widget_id = 1, unique_id = 1

Вторая база данных:

• В 1_settings у меня есть unique_id = 1, ..., где ... обозначает настройки виджета пользователя
• В 1_common у меня есть несколько строк, которые представляют общие данные между экземплярами одного и того же виджета (поэтому здесь нет данных, специфичных для пользователя)
• В 1_userdata у меня есть unique_id = 1, ..., где ... представляет данные виджета пользователя. Важным примечанием здесь является то, что эта таблица может содержать несколько строк с одинаковым unique_id (например, для виджета задач у пользователя может быть несколько задач для экземпляра виджета)

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

Теперь я хочу разработать «более чистую» схему, чтобы в моем приложении не было необходимости иметь 2 базы данных и каждый раз переключаться с одной на другую. Было бы также замечательно, если бы я нашел способ НЕ генерировать динамически таблицы во второй базе данных (1_settings, 2_settings, ..., n_settings).

Я буду очень признателен за любые попытки предложить лучший способ добиться этого. Заранее большое спасибо!

EDIT: Должны ли я иметь в виду базы данных вроде MongoDB или CouchDB при реструктуризации моих баз данных? Я имею в виду, для второй базы данных, где было бы лучше, если бы у меня не было фиксированной схемы. Кроме того, как традиционные SQL и NoSQL уживаются на одном сайте?

Answer 1

Возможная схема для таблицы users_widgets может быть:

id | user_id | widget_id

Вам не нужно поле unique_id в таблице users_widgets, если только по какой-то причине вы не хотите скрыть первичный ключ. На самом деле, я бы переименовал эту таблицу во что-то более запоминающееся, например widget_instances, и использовал бы widget_instance_id в остальных таблицах второй базы данных.

Одним из способов обработки второго набора таблиц является использование метаданных style:

widget_instance_settings

id | widget_instance_id | key | value

Это будет включать в себя userdata, потому что user_id связан с widget_instance_id, если только вы не хотите позволить пользователю создавать несколько экземпляров одного и того же виджета и по одной причине иметь одинаковые данные во всех экземплярах.

widget_common_settings

id | widget_id | key | value

Этот тип схемы можно увидеть в таких пакетах, как Elgg .

Answer 2

Знаете ли вы, какие настройки могут иметь класс виджета и его экземпляр? В этом случае в этих настройках можно сделать столбцы таблицы widget_class (для общих настроек) и widget_instance (например, для конкретных настроек).
Если вы их не знаете, то у вас может быть таблица widget_class_settings, которая имеет отношение многие к одному с таблицей widget_class, и таблица widget_instance_settings, которая имеет отношение многие к одному к таблице widget_instance. Между widget_instance и widget_class вы можете снова иметь отношение многие к одному. Элемент widget_instance также может иметь внешний ключ в таблице users, чтобы вы знали, какой пользователь создал определенный виджет.