Сохранение и получение состояния полей флажков из базы данных - PullRequest
0 голосов
/ 01 августа 2011

Наше приложение доступно через Интернет.Наши инструменты торговли: Java, JDK1.6, Apache Tomcat v6.0.10, PostgreSQL v8.2.3.

У нас есть страница / экран в приложении, которое получило ок.20 - 30 флажков, которые только обозначают состояние полей да / нет.

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

Мое решение / дизайн: Создание таблицы (USERPREFERENCE) с 3 столбцами: EMPLOYEEID, FIELDID,ГОСУДАРСТВО.Определите / назначьте каждое поле флажка по уникальному идентификатору / константе (1, 2, 3, ..., 30).Следовательно, в этой таблице будет 20-30 записей для каждого пользователя.Это нормально или есть какой-то другой / лучший способ эффективно справляться с этим на уровне базы данных?Кроме того, как мне автоматически отобразить состояние 20-30 полей (сохраняемых по строкам) из базы данных в объект JavaBean, чтобы упростить обработку возвратно-поступательных операций на уровне Java?

USERPREFERENCEТаблица выглядит следующим образом:

EMPLOYEEID | FIELDID | STATE
100        |   1     | true
100        |   2     | true
100        |   3     | false
...        |  ...    |  ...

Любые варианты советов / дизайна приветствуются и приветствуются.

ПРИМЕЧАНИЕ: Мы также разработали бы еще 4 страницы / экран с тем жефункциональность с 20-30 полями для флажков на каждом экране.

ОБНОВЛЕНИЕ: Пожалуйста, примите это во внимание: поля не являются фиксированными, в будущем могут быть добавлены новые поля.

1 Ответ

0 голосов
/ 01 августа 2011

Если поля имеют фиксированную длину и у вас есть значение для каждого поля для большинства ваших объектов (EMPLOYEEID), я бы выбрал отдельные столбцы boolean для каждого поля.Это более эффективно с двух точек зрения:

  • хранилище: вам не нужно хранить ключ (EMPLOYEEID, FIELDID) для каждого значения (а PostgreSQL умеет хранить логические значения)
  • простота использования: легко запрашивать и отображать значения в вашей модели
...