Каков оптимальный дизайн реляционной базы данных для хранения неизвестного числа похожих, но уникальных объектов

Question

База данных, которую мы разрабатываем, позволяет пользователям проходить проверку подлинности с помощью нескольких сторонних сервисов , в основном в социальных сетях (Twitter, Facebook и т. Д.).Там будет неизвестное и растущее число этих услуг.Каждый сервис требует уникальный набор данных для аутентификации, который не является стандартным для других сервисов .

Один пользователь может аутентифицировать многие сервисы , но они могут аутентифицироваться только с один из каждого типа из сервис .

ВозможноРешения:

A) Самое прямое решение этой проблемы - просто добавить столбец для каждой службы в пользовательскую таблицу , которая содержит аутентификацию JSON для этой службы.Однако это нарушает нормализацию, оставляя большое количество нулей в базе данных.Например, что происходит, когда существует 50 таких интеграций?

B) Каждый сервис получает свою собственную таблицу в базе данных.JSON больше не нужен, так как каждое поле может быть правильно описано.Затем для каждого сервиса необходима таблица соответствия «user_has_service».Это таблица, которая содержит только два внешних ключа, один для пользователя и один для службы, связывающих их вместе.Этот вариант кажется наиболее правильным, но он очень неэффективен и потребует многих операций, чтобы определить, какие сервисы имеет пользователь, увеличиваясь с увеличением количества сервисов.Я полагаю также, что в этом случае поле идентификатора для таблицы поиска должно быть неким хэшем user и service вместе, чтобы дублирующие вставки были невозможны.

Совсем не эксперт по базам данных, и я уже давно борюсь с этим.Есть мысли?

Answer 1

Вы можете установить:

• справочную таблицу с именем services для отображения списка всех доступных служб со столбцами, такими как service_id (первичный ключ), service_name и descriptions и так далее.Каждый сервис представлен как одна запись в этой таблице.

• таблица с именем services_properties для хранения свойств сервисов;эта таблица имеет 3 столбца: service_id (внешний ключ к первичному ключу services), property_name и property_value.Для кортежей service_id/propery_value может быть установлено уникальное ограничение, чтобы избежать дублирования.Каждый сервис имеет несколько записей в таблице services_properties.Эта гибкая структура позволяет хранить столько разных свойств, сколько необходимо для каждой службы, без создания новой таблицы для каждой службы

• таблицы сопоставления с именем user_services, которая связывает пользователей со службами.Столбцы будут service_id и user_id как внешние ключи к первичным ключам таблицы services и таблицы users.Вы можете запросить эту таблицу, чтобы легко перечислить услуги, подписанные каждым пользователем.