Java 1.5: Лучшая практика для сохранения констант для имени столбца таблиц БД?

Технологии: - Java 1.5 или 1.6 - Hibernate 3.4

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

У меня есть следующие вопросы?

  • Одно из возможных решений - поддерживать один глобальный файл, в котором хранятся константы для имен столбцов всех таблиц в базе данных. как

    class DbConstants
    {
            public static final String EMPLOYEE__PERFORMANCE_DESC="performance_desc";        
    } 
    

В приведенном выше случае сотрудники - это имя таблицы, а performance_desc - имя столбца. Таким образом, вид формата tablename__columnname используется для наименования константы, чтобы избежать столкновения между двумя константами из двух разных таблиц, если обе имеют имя столбца.

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

  • Предположим, если я изменил имя столбца в приведенном выше примере с performance_desc на достижения_desc. В этом случае очень вероятно, что я захочу также изменить константу, т.е. с EMPLOYEE__PERFORMANCE_DESC на EMPLOYEE__ACHIEVEMENT_DESC. Поскольку в этом случае мне нужно было изменить как имя столбца, так и имя константы, я не вижу особого смысла использовать константу вместо имени столбца непосредственно в моем коде, хотя есть одно преимущество, заключающееся в том, что при изменении имени константы я могу использовать преломление для отражения константы имя изменить имя везде, где есть ссылка. Кажется, либо использование констант не так уж много, либо я использую их неправильно.

  • В коде проекта мне кажется, что люди определяют один класс для каждого списка столбцов таблицы для определения констант, как показано ниже.

    public class tbl_Employee
    {
            public static final PERFORMANCE_DESC=performance_desc;
    }    
    

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

  • Прочтите кое-где о Enum со строкой значения, а не с int, не уверен, доступен ли он в java 1.5 или 1.6 и рекомендуется ли его использовать в данном сценарии.

  • Какова наилучшая практика для данного определения констант БД?

  • Действительно ли полезно использовать константы БД?

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

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

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

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


person Maddy.Shik    schedule 17.12.2010    source источник
comment
Не связанные с вопросом, ваши примеры нарушают соглашения об именах Java, используя двойные подчеркивания и имена классов, такие как tbl_Employee. Соглашения об именах Java действительно разумны и очень широко используются. Их действительно не стоит ломать без серьезной причины.   -  person Sergei Tachenov    schedule 17.12.2010
comment
@ Сергей Таченов: Полностью согласен, я использовал это неправильное соглашение об именах для примера. Но возникает один вопрос: как мне назвать класс, который определяет константы для таблицы, потому что, как и упомянутое соглашение об именах таблиц, не применяется к соглашению об именах классов.   -  person Maddy.Shik    schedule 17.12.2010
comment
Не делай этого. Вы неправильно используете базу данных, если чувствуете, что вам нужно решить эту проблему.   -  person Ronnis    schedule 18.12.2010


Ответы (5)


Похоже, вы задаете все правильные вопросы - вы хотите сделать код более удобным в сопровождении, но понимаете, что это может стать громоздким и в конечном итоге сделает код хуже, чем лучше. Подумайте о чем-то вроде «Цвет.КРАСНЫЙ, Цвет.ЧЕРНЫЙ».

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

  • они не будут часто меняться или, по крайней мере, не должны

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

Я видел такие файлы db с тысячами констант, включая пользовательские запросы, части запросов и т.д. На этом этапе они превращаются в строки «использовать один раз», и никто не осмеливается их менять.

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

person Steve B.    schedule 17.12.2010
comment
Мы не можем отрицать тот факт, что при переименовании имени столбца это действительно утомительная и непродуктивная задача воспроизвести одно и то же изменение в java-коде. Таким образом, мы не можем отказаться от констант, нам нужно какое-то решение, чтобы избежать эффекта множителя при изменении базы данных. Как я указал, одно из преимуществ константы, даже если мы изменим само имя константы, - это средство рефрактора в затмении. Меня больше всего беспокоит то, что должно быть лучшим подходом для организации глобальных констант, классов, интерфейсов или перечислений для каждой таблицы или чего-то еще. - person Maddy.Shik; 17.12.2010

Рассматривали ли вы использование Entity Mapping Framework (например, Hibernate)?

Он может хранить всю информацию таблицы базы данных (а также всю другую информацию, относящуюся к базе данных) в файле конфигурации. Он также предлагает разделительный слой между «жестким» дизайном БД и вашим приложением (что упростит внесение изменений в любую из них).

person Jonathan B    schedule 17.12.2010
comment
Я использую аннотацию Hibernate для сопоставления класса Entity с таблицей. Но могут быть некоторые запросы к базе данных, которые не могут быть решены с помощью спящего режима, поэтому то же самое реализовано с использованием запроса sql, а не спящего режима на уровне Dao. - person Maddy.Shik; 17.12.2010
comment
Вы также можете встроить стандартный SQL-запрос в файлы конфигурации Hibernate. Это означает, что любое изменение БД потребует соответствующего изменения файла конфигурации, но это позволяет вам, чтобы изменения БД влияли только на одно место (и не требует перекомпиляции для работы). См. Документацию по Hibernate в разделе «Собственные запросы SQL». - person Jonathan B; 17.12.2010
comment
(1). Я использую аннотацию спящего режима, а не файл отображения спящего режима. Таким образом, изменения будут в нескольких файлах (2). Есть некоторые бизнес-запросы, на которые нельзя ответить с помощью hibernate pojo, поэтому мне нужно писать код вне контекста спящего режима для того же на уровне DAO. Спасибо - person Maddy.Shik; 17.12.2010
comment
Hibernate также предоставит вам необработанные данные, если вы не укажете конкретное сопоставление объекта POJO в запросе. Таким образом, вы можете написать HQL с оператором select, а возвращаемый Iterator (или List) представляет собой список Object [], который содержит данные, возвращенные из запроса. - person Jonathan B; 20.12.2010
comment
Аннотации - это компромисс между легко читаемым кодом и более сложным сопровождением кода. Это непростой вызов - делайте то, что лучше всего подходит для вас. - person Jonathan B; 20.12.2010

В моем текущем проекте мы активно используем аннотации для многих метаданных, связанных с БД, потому что мы не можем использовать фреймворк, такой как Hibernate. Для фактических констант столбцов, да, мы используем проверенный и верный public static final String. И да, он довольно хрупкий.

person Daniel DiPaolo    schedule 17.12.2010
comment
Даниэль ДиПаоло: Вы используете один глобальный файл или один класс для каждой таблицы? - person Maddy.Shik; 17.12.2010
comment
Один класс на таблицу, хотя он не привязан строго к имени таблицы, это также константа внутри класса :) - person Daniel DiPaolo; 17.12.2010

Вы можете создать интерфейс, определяющий константы.

Вот хороший пример для Android. Ищите DataColumns интерфейс.

person Don    schedule 17.12.2010
comment
Выглядит хорошо, но я думаю, что интерфейс или класс для обоих - нецелесообразно использовать их только с единственной целью определения констант. Но, безусловно, эта ссылка отражает практику, которой следуют, поэтому может быть полезной. Но требуются константы для имени таблицы, которые не рассматриваются в этом коде. - person Maddy.Shik; 17.12.2010

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

person Peter Lawrey    schedule 17.12.2010