Лучшая практика: лучшее соглашение о присвоении имен для JPA?

В Java соглашение об именах для свойств en classes (entity) выполняется CamelCase способ:

@Entity 
public class UserMessage implements Serializable { 
    @Id 
    private Integer id; 
    private String shortTitle;
    private String longTitle;
    private String htmlMessage; 
}

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

CREATE TABLE USER_MESSAGE (
    USER_MESSAGE_ID  MEDIUMINT(8) NOT NULL,
    USER_MESSAGE_SHORT_TITLE VARCHAR(20),
    USER_MESSAGE_LONG_TITLE VARCHAR(80),
    USER_MESSAGE_HTML_MESSAGE TEXT NOT NULL
);

Должен ли я выполнять оба стандарта и использовать атрибут name в @Table и @Column? Или я должен следовать соглашениям Java и полагаться на сопоставления JPA по умолчанию.

Каков наиболее распространенный подход и/или лучший подход к этому конфликту стандартов?

ОТВЕТЫ

Ответ 1

Должен ли я выполнять оба стандарта и использовать атрибут name в @Table и @Column? Или я должен следовать соглашениям Java и полагаться на сопоставления JPA по умолчанию.

Если соглашения по умолчанию JPA не соответствуют предпочтительным соглашениям вашей компании (нет "одного истинного" стандарта), переопределите их. Это можно сделать с помощью аннотаций @Table и @Column (в конкретном случае Hibernate вы также можете предоставить свою собственную реализацию NamingStrategy).

Каков наиболее распространенный подход и/или лучший подход к этому конфликту стандартов?

Не существует конфликта, существуют соглашения об именах Java, существует соглашение one по умолчанию на стороне JPA для сопоставления объектов с таблицами (поскольку JPA пришлось выбрать один) и там не является "одним истинным" стандартом на стороне SQL. Итак:

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

Ответ 2

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

Ответ 3

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

  • Длинные, значимые имена лучше коротких имен, например. TRANSACTION_DATE, а не TRAN_DT. Да, я достаточно взрослый, чтобы написать Fortran, когда вы ограничились 6-символьными именами переменных, и я вспоминаю основные варианты, в которых у вас был только AZ, A0-Z0... A9-Z9 - но я тоже достаточно взрослый чтобы учиться лучше. Односимвольные имена переменных для индексов и т.д. Являются точными - и на самом деле традиционными - но когда я нахожу функцию с двенадцатью однобуквенными именами переменных, которые используются для нескольких целей, я не удивлен.

  • Искусственные первичные ключи называются ID_ < "name of table" → .

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

  • Никогда, никогда, никогда не рассчитывайте на дату, время или поле даты/времени, чтобы быть уникальным. Когда-либо. Не забывайте об этом. Я имею в виду.

  • Обфускаторные методы кодирования эквивалентны некомпетентности.

Я уверен, что там больше, но это начало. Все ИМХО. YMMV.

Поделитесь и наслаждайтесь.

Ответ 4

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

Взгляните на класс Hibernate org.hibernate.cfg.ImprovedNamingStrategy. Он использует символы подчеркивания вместо случая верблюда. Это просто вопрос установки свойства в вашей конфигурации Hibernate для его использования.

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