Как я могу просто сохранить несколько критериев/логики списка рассылки в базе данных?

Вопрос:

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

  • Один тип клиента (бизнес или жильё, один или другой, не оба, нуль не является допустимым вводом)
  • Единая область обслуживания (SA1, SA2, SA3, SA4, одна и только одна)

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

Однако проблема возникает при попытке сохранить определяющие критерии для каждого списка рассылки. Критерии для списка рассылки могут представлять собой любую комбинацию типов клиентов (только для жилых помещений, только для бизнеса, для жилых помещений и бизнеса) и зоны обслуживания (например, Residential SA1 отличается от Business SA1, отличается от Business и Residential SA2). Моим первоначальным решением было использовать два столбца customerType и ServiceArea и иметь отдельные списки, содержащие типы клиентов и зону обслуживания для каждого списка рассылки. Я хотел бы избежать этого, чтобы моя база данных могла поддерживать некоторое подобие 3NF. Мне также хотелось бы избежать столбца для каждого типа клиента и каждой области обслуживания.

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

Лучший ответ:

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

Сказав, что если SA1, SA2, SA3… подлежат удалению и/или переименованию, я бы не использовал список для этого. Некоторые отношения, подобные приведенным ниже, будут работать, если вы должны использовать 3NF.

CustomerServiceAreaFilter
CustomerServiceAreaFilterID (ПК)
Идентификатор_пользователя (ФК)
CustomerType (ФК)
** Уникальный индекс в UserID и CustomerType

CustomerServiceAreaFilterServiceArea
CustomerServiceAreaFilterServiceAreaID (ПК)
CustomerServiceAreaFilterID (ФК)
ServiceAreaID (ФК)
** Индекс Uniqe на CustomerServiceAreaFilterID ServiceArea

Ответ №1

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

2 ^ customer type + (2 ^ service area) * 2 ^ (maximum customer type value)

На практике для ваших клиентов это означает, что каждый клиент будет иметь следующее:

100010
100001
010010
010001
001010
001001

левые 4 цифры являются двоичными для зоны обслуживания, справа 2 цифры – тип клиента

Таблица критериев может быть одной с тремя столбцами:

| distribution_list_id | criteria_id | group |

При определении членов дистрибутива запросите таблицу критериев для всех строк, соответствующих идентификатору списка рассылки, группируя по столбцу group и выбирая сумму criteria_id. Выделите все строки из клиентов, которые join к этой таблице критериев, при этом их расчетные битовые флаги равны типу клиента. Назначение столбца group – это позволить вам and вместе, в то время как отдельные строки с разными значениями group в таблице критериев указывают or.

Предполагая, что вы записываете хорошо документированные хранимые процедуры для вставки в эти таблицы, вся часть “изменения в бит-логике” не должна становиться слишком волосатой, и цель состоит в том, чтобы позволить вам легко делать and произвольное количество критериев, основанных на на group (sum намного проще, чем объединение строк в group by). Таким образом, когда клиенты неизбежно получат больше свойств, как всегда, вы можете просто добавить больше бит в конец для другого набора свойств без изменения вашей схемы.

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

-Edited для опечаток

Оцените статью
TechArks.Ru
Добавить комментарий