Каков наилучший способ сохранить значение из списка предварительно определенных значений в базе данных? - PullRequest
5 голосов
/ 22 июня 2010

Допустим, у меня есть предварительно определенный список значений ( RW, FW, 4W ), представляющих тип привода транспортного средства:

RW - заднее колесо

FW - Front Wheet

4W - Четыре колеса

Теперь я хочу взять значение из 3 приведенных выше значений в качестве ввода от моего пользователя и затем сохранить его в базе данных.

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

- Жесткое кодирование значений в пользовательском интерфейсе, чтобы пользовательский интерфейс отображал раскрывающийся список, содержащий только 3 вышеуказанных значения. Затем сохраните это значение в поле String vehicleType объекта Vehicle vehicle и сохраните его в БД как String.

  • Минусы:

    я). Нет проверки значения на уровне объекта

    * 1 035 * II). Нет проверки значения на уровне БД.

    Ш). Хотя необходимость добавления нового значения в список встречается редко, но пользователь не может добавить новое значение во время выполнения

    - Плюсы:

    я). Нет необходимости join в БД для получения vehicle объекта

OR

  • Создайте отдельную таблицу VEHICLE_TYPE в БД, имеющую все 3 значения, и свяжите ее с таблицей VEHICLE через. иностранный ключ. А затем заполните раскрывающийся список UI из таблицы VEHICLE_TYPE. Сохраните значение в объекте vehicle как String

    - Минусы:

    я). Нет проверки на уровне объекта

    * * Тысяча шестьдесят-восемь II). Требуется join в БД для получения vehicle объекта

    - Плюсы:

    я). проверка значения на уровне БД (по внешнему ключу)

    б). Пользователь может добавить новое значение в список во время выполнения

OR

  • Создайте отдельную таблицу VEHICLE_TYPE в БД, имеющую все 3 значения, но НЕ связывает ее с таблицей VEHICLE через иностранный ключ. А затем заполните раскрывающийся список UI из таблицы VEHICLE_TYPE. Сохраните значение в объекте vehicle и в БД как String

    - Минусы:

    я). Нет проверки на уровне объекта

    б). Нет проверки на уровне БД

    - Плюсы:

    я). Нет join требуется на уровне БД

    б). Пользователь может добавить новое значение в список

OR

  • Создайте отдельную таблицу VEHICLE_TYPE в БД, имеющую все 3 значения, и свяжите ее с таблицей VEHICLE через. иностранный ключ. А затем заполните раскрывающийся список UI из таблицы VEHICLE_TYPE. Сделайте enum VehicleType в Java, а затем добавьте поле VehicleType vehicleType в Vehicle классе. Сохраните значение из перечисления VehicleType в поле vehicleType на основе ввода пользователя.

    -Cons:

    я). Придется обновить список в двух местах: VehicleType enum и таблица VEHICLE_TYPE. Может вызвать несоответствие.

    б). Пользователь не может добавить новое значение в список (он может добавить значение в таблицу, но не может изменить перечисление)

    - Плюсы:

    я). проверка на уровне пользовательского интерфейса

    б). проверка на уровне объекта

    Ш). проверка на уровне БД

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

Ответы [ 4 ]

2 голосов
/ 22 июня 2010

Конечно.Ваш второй с модификацией:

Создайте отдельную таблицу VEHICLE_TYPE в БД со всеми 3 значениями и свяжите ее с таблицей VEHICLE черезиностранный ключ.А затем заполните раскрывающийся список UI из таблицы VEHICLE_TYPE.Сохраните значение в объекте транспортного средства как String.При вызове vehicle.setVehicleType() убедитесь, что присвоенное значение действительно, проверив возможные значения из БД.Если это недопустимо, бросьте InvalidArgumentException или подкласс.

Теперь у вас есть проверка в объекте.А также, я не считаю, что нужно вступать в мошенничество.Вы ничего не можете сделать, не присоединившись к столам.Вот почему у вас много таблиц.

1 голос
/ 22 июня 2010

Создайте отдельную таблицу Vehicle_type (Vehicle_type_id int, описание varchar (вам необходимо определить подходящий размер)), чтобы использовать ее в качестве раскрывающегося меню. Если вы хотите, чтобы значение изменялось в основной таблице при изменении поиска (скажем, адимин меняет седен на седан), сохраните typeid в таблице транспортных средств. Если вы хотите, чтобы это были исторические данные (возможно, больше нет седана типа, но более старые автомобили должны быть помечены как седан), сохраните описание типа в таблице транспортных средств. Во втором случае вы не можете применить с помощью отношения FK, поэтому вам нужно убедиться, что вставки (и обновления только этого значения) не могут выбирать значения, которых в данный момент нет в таблице. Приложение, скорее всего, сделает это, хотя вы можете написать триггер для этого, если значения могут измениться вне приложения.

1 голос
/ 22 июня 2010

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

Способ обработки дополнительных значений, введенных пользователем, зависит от того, как вы хотите, чтобы они обрабатывались:

  1. Рассматривайте их как истинные дополнительные значения.Они добавляются в VEHICLE_TYPE в базе данных и после добавления доступны для выбора всем пользователям.

  2. Рассматривать их как пользовательские значения для этого конкретного поля.Т.е. VEHICLE_TYPE включает в себя тип «Other», и пользователь может вводить дополнительные данные в отдельном поле.Они не предоставляются другим пользователям и не отображаются в раскрывающемся списке.

Чтобы получить проверку на уровне объекта, выполните проверку на соответствие VEHICLE_TYPE.Это может быть сделано автоматически с современными OIM и ORM.Они позволяют вам определять правила проверки для модели, которые затем передаются вперед в пользовательский интерфейс для раннего обнаружения ошибок проверки и обратно в базу данных для обеспечения согласованности хранилища данных.

Вы можете хранить идентификатор транспортного средства как обычный ключили сама строка типа (RW, FW и т. д.).При использовании самой строки типа вам не нужно присоединяться к таблице VEHICLE_TYPE.Вы можете представить строку напрямую или выбрать строки представления из комплектов ресурсов, если требуется локализация.

РЕДАКТИРОВАТЬ: чтобы увидеть, как ORM и OIM могут переносить метаданные проверки модели обратно в БД и в пользовательский интерфейс.см. DZone: Проверка подлинности Hibernate 4 и Метавиджет .С помощью JSR 303 вы можете проверять свои объекты в пользовательском интерфейсе, бизнес-уровне и серверной части.

1 голос
/ 22 июня 2010

Я бы выбрал и второй подход. Тебе уже ответили о первом мошенничестве.

Что касается второго довода "против", если производительность так важна, вы можете использовать один из этих подходов:

  1. Если тип транспортного средства не используется в приложении, ленивая загрузка типа транспортного средства.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...