Вопрос проектирования - Поместите сотни переключателей «Да / Нет» в столбцы, строки или другие?

Question

Мы портируем старое приложение, которое использовало иерархическую базу данных, на реляционное веб-приложение и пытаемся найти лучший способ для переноса переключателей конфигурации (значения Y / N).

В нашей старой системе было 256 различных коммутаторов (для каждого клиента), каждый из которых был сохранен как бит в одном из 8 32-битных полей данных. Каждый клиент обычно имеет ~ 100 переключателей. Чтобы прочитать или установить переключатель, мы использовали бы побитовую арифметику, используя значение #define. Например:

if (a_switchbank4 & E_SHOW_SALARY_ON_CHECKS) //If true, print salary on check

Мы обсуждали, какой подход хранить коммутаторы в нашей новой реляционной (MS-SQL) базе данных:

1. Поместите каждый переключатель в свое поле
   • Плюсы: быстрое и простое чтение / запись / доступ - 1 строка на клиента
   • Минусы: кажется хитрым, нужно менять схему каждый раз, когда мы добавляем переключатель
2. Создать строку для каждого коммутатора для каждого клиента
   • Плюсы: неограниченное количество переключателей, без изменений схемы с новыми переключателями
   • Минусы: немного труднее извлекать данные, потерять intellisense без дополнительной работы
3. Ведение битовых полей
   • Плюсы: можно использовать один и тот же код, меньшие объемы передачи XML-данных между машинами
   • Минусы: не имеет никакого смысла для наших разработчиков, сложно отлаживать, слишком легко использовать неправильное поле 'switch bank' для сравнения

Я склоняюсь к # 1 ... есть мысли?

Answer 1

Это зависит от нескольких факторов, таких как:

• Сколько переключателей установлено для каждого клиента
• Сколько переключателей фактически используется
• Как часто добавляются переключатели

Если бы мне пришлось угадывать (и я бы угадывал), я бы сказал, что вы действительно хотите, это теги. В одной таблице есть клиенты с уникальным идентификатором для каждой, в другой - теги (имя тега и уникальный идентификатор), а в третьей - пары «идентификатор клиента / идентификатор тега», чтобы указать, какие клиенты имеют какие теги.

Это отличается от вашего решения № 2 тем, что теги присутствуют только для клиентов, для которых этот переключатель имеет значение true. Другими словами, вместо сохранения идентификатора клиента, идентификатора коммутатора и логического значения вы сохраняете только идентификатор клиента и идентификатор коммутатора, но только для клиентов с этим набором коммутаторов.

Это занимает примерно одну треть пространства над решением номер два, но реальное преимущество перед решениями один и три: индексация. Если вы хотите выяснить, например, у каких клиентов установлены переключатели 7, 45 и 130, а не 86 или 14, вы можете сделать это эффективно с помощью одного индекса в таблице тегов, но практического способа сделать это с другими решения.

Answer 2

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

Answer 3

Помните также, что если вы измените метод, у вас может быть много кода приложения для изменения, которое зависит от существующего метода хранения данных. Нужно ли менять метод, может зависеть от того, насколько это будет сложно и сколько часов потребуется, чтобы изменить все связанное. Я согласен с решением Маркуса, но вам нужно точно подумать, насколько сложным будет рефакторинг и сможет ли ваш проект позволить себе время. Книга рефакторинга, которую я читал, предложила бы вам поддерживать оба в течение установленного периода времени с триггерами, чтобы синхронизировать их, а затем начать исправлять все ссылки. Затем в установленную дату вы удаляете оригинал (и триггеры) из базы данных. Это позволяет вам использовать новый метод, но дает гибкость, что ничто не сломается, прежде чем вы исправите его, так что вы можете развернуть изменение до того, как все ссылки будут исправлены. Однако это требует дисциплины, так как легко не избавиться от устаревшего кода и столбцов, потому что все работает, и вы боитесь этого не делать. Если вы находитесь в процессе полной реорганизации, где все будет тщательно протестировано, и у вас есть время, встроенное в проект, тогда продолжайте и все измените сразу.

Answer 4

Я бы выбрал вариант № 2, по одной строке на флаг.

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

Answer 5

Я бы порекомендовал вариант 2. Превратить список тегов / строк в хеш в коде относительно просто, что позволяет довольно легко проверять переменные. Наличие таблицы с 256+ столбцами кажется кошмаром.

Одна из проблем, связанных с вариантом №2, заключается в том, что наличие перекрестного запроса является проблемой:

Client   S1 S2 S3 S4 S5 ...
A            X     X
B         X  X  X

Но обычно есть способы сделать это специфичным для базы данных способом.

Answer 6

Я бы также склонялся к варианту 1, но в некоторых сценариях также рассмотрел бы вариант 4.

4 - Хранить в словаре пар имя-значение. Сериализация в базу данных.