Вопрос моделирования данных

Question

Мои клиенты используют одно из следующих средств при регистрации в моем приложении:

1. Foo API (требуется " auth_key ", " пароль ", " email ")
2. Acme API (требуется " secure_code ", " имя пользователя ", " пароль ")
3. Bar API (требуется " xyz_code ", " pass_key ")

(поддельные имена и еще 15 опущены для простоты)

Я бы предпочел не иметь 10-15 таблиц в моей базе данных только для разных вариантов интеграции API, которые я предлагаю (особенно когда они все для одной и той же вещи, и они просто выбирают 1 из всего списка).

Мое решение было таким:

Создайте таблицу api_configuration со столбцом api_name, который содержит код для определенного API (например, "foo_api")

Создайте таблицу с именем credentials_attribute с внешним ключом обратно к api_configuration, столбец с именем name и столбец с именем value.

Затем я создаю пользовательский интерфейс для выбора API. Если они выберут Acme API, он запросит «secure_code», «username» и «password» и создаст строку в credentials_attribute для каждой пары имя / значение.

На моей модели ORM для api_configuration я могу создать метод для поиска credentials_attribute значений на основе текущих api_name.

Чувствуется ли это решение правильным или есть другой способ сделать это, если бы вам пришлось смоделировать решение для этой проблемы? Пожалуйста, объясните ваше обоснование (например, лучше для производительности и т. Д.)

Answer 1

Я бы предпочел сделать это с одной таблицей

Иметь одну UserAuthentication таблицу с такими столбцами, как IdentificationKey, AuthenticationCriteria1, AuthenticationCriteria2 и т. Д. *

Количество AuthenticationCriteriaX столбцов = максимальное количество критериев, которое будет иметь любой API. Я предполагаю, что это будет что-то разумное, например, максимум 5, но все до 15-20 на самом деле все еще довольно маленький стол.

Таблица

UserAuthentication также содержит столбец api_key, который является внешним ключом таблицы MASTER_API, которая является списком всех поддерживаемых API

Что касается части проблемы с пользовательским интерфейсом, т. Е. Какой метки показывать пользователю для любого поля из таблицы UserAuthentication, я думаю, что это всего лишь проблема с пользовательским интерфейсом, и поэтому вы должны иметь отображение, специфичное для каждого API где-то в вашем слое пользовательского интерфейса. Столбец api_key может использоваться для перевода по мере необходимости. БД не обязательно должна знать эти детали, ИМО.

Answer 2

Если я правильно понимаю случай, он выглядит как еще один случай шаблона проектирования gen-spec. Посмотрите "Обобщение специализации реляционного моделирования".

Учебные пособия по объектному моделированию обычно охватывают общие спецификации, но учебные пособия по реляционному моделированию часто этого не делают. Но это хорошо понимают, и в Интернете есть несколько отличных статей.

Answer 3

Если я правильно вас понимаю, все эти свойства в разных API-интерфейсах концептуально являются кортежами из одной и той же вещи под разными именами, верно?

Ваше описание с точки зрения БД - я опишучто бы я делал на стороне домена (что может быть напрямую сопоставлено с вашей схемой).

Я бы создал один класс, например, UserLogin, с 3 свойствами, упомянутыми выше (например, authenticationCode, userId, password), и сопоставление имен / кодов API с именами свойств GUI.Когда пользователь выбирает предпочтительный API, я могу отображать поля с соответствующими именами в графическом интерфейсе и заполнять значения до соответствующих свойств UserLogin.При необходимости UserLogin также может сохранить предпочтительный API входа для этого пользователя.Таким образом, UserLogin отображается в одну таблицу на стороне БД.Я могу использовать другую таблицу для настройки имен свойств для каждого известного API.