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

Question

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

0

Я заметил, что большинство соглашений об именах в системах реляционных баз данных на протяжении всей моей карьеры всегда были в формате app1_feature1_person с использованием подчеркивания в качестве разделителя слов. Проблема, с которой я столкнулся, связана с моими личными отношениями с подчеркиванием при кодировании, его комбинацией клавиш Shift, которая всегда требует больше усилий при наборе кода, и это не соответствует моей стратегии пространства имен в Java, где я хотел бы изменить имя таблицы выше для com.mycompany.app1.feature1.Person.

Мне интересно, существуют ли какие-либо веские причины, по которым общее соглашение об именах основано на подчеркивании, и если добавление пространства имен с разделителями точками в мое имя таблицы является плохой практикой проектирования. (Используя MySql)

Duncan Krebs 28 нояб. 2018, в 20:18

Источник

2

Если бы я унаследовал эту схему, у меня было бы несколько слов для выбора моего предшественника.
Strawberry 28 нояб. 2018, в 18:24
0

@Strawberry Клубника, можешь рассказать подробнее?
Duncan Krebs 28 нояб. 2018, в 18:25
5

Ваш выбор между использованием подчеркивания ( app1_feature1_person ) или использованием app1_feature1_person и цитированием идентификатора ( "app1.feature1.person" ). Цитирование - это боль в шее и очень подвержено ошибкам, поэтому я бы остановился на подчеркивании.
The Impaler 28 нояб. 2018, в 18:37
0

Не без нарушения SO правил
Strawberry 28 нояб. 2018, в 18:37
0

Точки в Java не являются частями имен. Мы можем разумно сказать, что точки используются в SQL так же, как они используются в Java.
philipxy 28 нояб. 2018, в 20:32

Показать ещё 3 комментария

Теги:

mysql

sql

relational-database

1 ответ

Ещё вопросы

Если бы я унаследовал эту схему, у меня было бы несколько слов для выбора моего предшественника.
@Strawberry Клубника, можешь рассказать подробнее?
Ваш выбор между использованием подчеркивания ( app1_feature1_person ) или использованием app1_feature1_person и цитированием идентификатора ( "app1.feature1.person" ). Цитирование - это боль в шее и очень подвержено ошибкам, поэтому я бы остановился на подчеркивании.
Точки в Java не являются частями имен. Мы можем разумно сказать, что точки используются в SQL так же, как они используются в Java.

fancyPants · Answer 1 · 2018-11-28T15-40-00.000Z

0

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

fancyPants 28 нояб. 2018, в 15:40

0

Это хороший момент, что вы думаете об использовании дефиса (-) всего, что угодно, чтобы избавиться от подчеркивания.
Duncan Krebs 28 нояб. 2018, в 18:29
0

Также должен быть указан дефис, который для меня запрещен. Но если тебе так хочется, иди к этому. Кроме того, я на самом деле интересуюсь именами ваших столов. Я никогда не сталкивался с базой данных, где такие загадочные имена были необходимы. Разные приложения обычно используют разные схемы. И если у вас все еще есть загадочные имена, вы также можете спросить, правильно ли нормализована ваша схема.
fancyPants 28 нояб. 2018, в 18:37
1

@duncankrebs дефис, во всяком случае, хуже. Он может вызвать катастрофическую ошибку, даже не подозревая об этом!
Strawberry 28 нояб. 2018, в 18:38
0

Клубника на самом деле имеет хорошую точку зрения. Не думал об этом. Но для этого вам понадобится столбец a и b если вы забудете процитировать столбец ab .
fancyPants 28 нояб. 2018, в 18:46
2

Предыдущие комментарии касались проблем с использованием «.» в именах вашей таблицы. Учитывая имя, например «app1_feature1_person», я хотел бы спросить, есть ли у вас другая таблица с именем «app2_feature1_person» с той же схемой, что и в первой таблице, но с другими данными? Если такие таблицы являются попыткой предоставить какое-то мультитенантное решение, я бы предложил создать отдельную «схему базы данных» для каждой таблицы арендаторов. Каждую базу данных арендаторов можно настраивать, размещать, резервировать, управлять и настраивать независимо от других.
Tom Drake 28 нояб. 2018, в 20:21
0

@Tom Drake, спасибо за совет, я думаю, у вас есть два хороших момента, которые разделяют мои схемы, несмотря на то, что это одно приложение OSGI с множеством плагинов, которые имеют различные функции, это облегчит жизнь, во-вторых, сделает мою стратегию именования более нормализованной и, наконец, решит проблему с использованием подчеркивания.
Duncan Krebs 28 нояб. 2018, в 20:55
0

@ Tom Drake, вы совершенно правы, проблема в том, что я на начальной стадии альфа-версии довольно сложной автоматизированной торговой системы с несколькими плагинами OSGI, все из которых предлагают новые функции, и я подумал о том, чтобы просто начать с одного дБ для имен таблиц префиксов. с функцией, а затем разбить на различные схемы, когда это необходимо, но, вероятно, следует просто сделать это сейчас. Еще раз спасибо
Duncan Krebs 29 нояб. 2018, в 03:21

Показать ещё 5 комментариев