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

Question

В Java соглашение об именах для свойств и классов (сущностей) выполняется следующим образом: 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 по умолчанию.

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

Answer 1

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

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

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

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

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

Answer 2

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

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

2. Искусственные первичные ключи имеют имя ID _ << "имя таблицы" >>.

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

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

5. Методы запутанного кодирования эквивалентны некомпетентности.

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

Делись и наслаждайся.

Answer 3

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

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

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

Answer 4

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