Специальные свойства объекта и нормализация базы данных

Question

Предположим, у меня есть объект клиента, который имеет все стандартные свойства клиента (имя, адрес, контакт и т. Д.). Мы получаем нового клиента (Acme), у которого есть очень специфический запрос, который мы высылаем на счет-фактуру, который имеет наш идентификатор в виде штрих-кода. Мы не хотим этого для всех других клиентов, поэтому мы намерены сделать это как особый случай для Acme. Теперь давайте предположим, что многие клиенты имеют эти небольшие одноразовые запросы. Что бы лучший способ режима эти данные:

Я вижу пару возможностей и их преимущества/компромиссы:

1) Запрограммированные в точке отклонения, проверка для идентификатора или имени клиента.
Преимущества: Наименьшее усилие, единственная точка интеграции
Компромиссы: неаккуратный код, сильно подверженный ошибкам. Для изменения флажков требуется новое развертывание. Трудно найти отклонения по мере роста свойств.

2) Столбцы БД на Клиенте для каждого объекта. Флаги будут установлены как истинные для одного клиента, а для остальных - ложные.
Преимущество: относительно просто, свойства могут быть изменены «на лету»
Компромисс: делает очень широкие базы данных и неряшливую схему. По мере добавления дополнительных свойств данные становятся все более неуправляемыми. Код также будет неаккуратным, так как многие ненужные свойства должны быть сопоставлены.

3) Отображение жестко заданных свойств. Карта, которая обладает специальными свойствами для клиентов. Затем карту можно запросить для специальных свойств, и поток кода может идти оттуда.
Преимущества: Единая точка управления.
Недостаток: жесткий. Идентификаторы клиентов/Имена будут в коде. Для внесения изменений требуется развертывание.

4) Таблица CustomerProperty с столбцами ключа/значения.
Преимущества: Чистота. Единая точка управления. Динамический.
Недостатки: Относительный комплекс, по сравнению с другими решениями.

Очевидно, что выбор будет зависеть от обстоятельств. Если у нас будет сотни отклонений, важно иметь единую точку управления. Если бы это было действительно одноразовое отклонение, я думаю, что № 1 будет в порядке, хотя и хакерским.

У меня есть мнение о том, что лучше в этом случае .... но я хотел бы знать мнения других.

Answer 1

Я бы пошел с опцией 4. Из опыта, когда я выбрал более быстрые варианты, результатом было неизбежно внедрение оптимального решения, и взлом вызвал только проблемы. Я всегда стараюсь подходить к этим проблемам с точки зрения домена, и в этом случае 4 является лучшей моделью. Разница в реализации минимальна по сравнению с содержанием всех артефактов и возможного рефакторинга, которые вам нужно будет сделать.

Answer 2

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

Answer 3

Я сделал много 1) по предыдущему моему проекту и в конечном итоге перешел к решению, например, номер 4). Я использовал расположение своих хаков, чтобы поместить крючки для настройки. Определенно было легче управлять, особенно по мере того, как запросы на настройку росли.

Первоначально предполагалось, что 2) будет работать для вашего конкретного сценария (не учитывая предполагаемые дополнительные запросы на настройку, просто запрос штрих-кода), поскольку я предположил, что другим клиентам также может понадобиться штрих-код для их счетов-фактур. Тем не менее, я также мог видеть, что они хотят, чтобы штрих-кодированная информация была в другом формате, чем то, что вы изначально разработали для первого клиента, так что это потенциально может привести к проблеме, с которой вы начали.

Итак, я говорю, идите с 4) и, следовательно, реализуйте отношения «многие-ко-многим» между вашими объектами настройки и объектами вашего клиента. Первоначально в настройках настройки не должно быть больше значений для выполнения операторов switch в коде приложения, где должна выполняться настройка.