powered by simpleCommunicator - 2.0.47     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / подскажите хорошую практику наименования связанных таблиц
25 сообщений из 132, страница 1 из 6
подскажите хорошую практику наименования связанных таблиц
    #39996327
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго дня. Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы.
Есть справочник клиентов CLIENTS, ключевое поле CLID, есть справочник льгот BENS, ключевое поле BNID и есть таблица со связью клиента и льгот. Как красиво ее назвать (таких троек таблиц будет много по разным сущностям), и как понятно назвать связывающую таблицу и ее поля (пара клиента и льготы)?
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996337
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CLIENTS_BEANS
CLID
BNID

Особо извращённые MS SQL пользователи могут использовать [Clients<->Bens].
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996341
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Тогда надо алиасы таблиц указывать в запросе, так как поля имеют одинаковое название.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996342
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin,

Алиасы таблиц в запросах лучше указывать всегда.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996366
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
... академическое красивое решение ...

Нету такого. Каждый лепит от балды.
Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996370
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Злой Бобр
GrigoriyFomin
... академическое красивое решение ...

Нету такого. Каждый лепит от балды.
Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним.

А потом придет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма под одобряющее улюлюканье коллег по цеху, который будут предлагать свои решения )
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996373
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма

Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996376
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы

Во-первых, справочник клиентов, как и другие таблицы, назвать в единственном числе - client.
Во-вторых, его первичный ключ назвать client_id.
В-третьих, справочнику льгот дать нормальное и подходящее по бизнес-логике название в единственном числе. Например, privilege. Его первичный ключ, соответственно, назвать privilege_id.
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996382
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма

Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика".

мне 38, програмлю 25 лет, начиная с ZX Spectrum и я не слышал про базу болтика ) гугль тоже ничего не выдал. ЧЯДНТ! Я комплексую!
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996383
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей. Так, справочник контрагентов CONTRAGENTS проще назвать CAS, сотрудников EMPS, ну и в таком роде.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996399
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Во-вторых, его первичный ключ назвать client_id.

И получится client.client_id. Зачем? Почему не делать все первичные поля id, а внешние - client_id.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996400
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin,

У нас - так: первичный ключ - везде id, внешний ключ - fk_имя_таблицы, связанные таблицы table1xtable2, если совсем туго с именем.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996405
Dimkas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
crutchmaster
softwarer
Во-вторых, его первичный ключ назвать client_id.

И получится client.client_id. Зачем? Почему не делать все первичные поля id, а внешние - client_id.


Могу пояснить свою собственную логику для такого случая:
Вот есть таблица клиентов - client(id integer, name varchar),
рядом таблица подразделений - department(id integer, name varchar)
Как будет выглядеть таблица "Связь клиентов и подразделений"?
Наверное что-то типа client_department(id integer, client_id integer, department_id integer), так?

А как выглядит запрос списка департаментов и обслуживаемых ими клиентов?
Очевидно
Код: plsql
1.
2.
3.
select d.name department_name, c.name client_name from
department_client d_c, department d, client c where
d_c.client_id = c.id and d_c.department_id = d.id



Так вот в этом запросе есть два момента, которых лично мне хочется избежать:
1. Лишнее переименование d.name в department_name - хочется обойтись без переименования вообще.
2. Связь вида d_c.client_id = c.id - где связываемые поля имеют разные названия, хочется связывать поля с одинаковыми названиями.

Поэтому у нас все таблицы, в которых хранятся сущности, имеют структуру вида
client(idclient integer, client varchar, ...)
и поля-ссылки на таблицу client всегда начинаются с idclient,
И только если клиентов в одной таблице больше одного, то используем что-то типа idclient_1, idclient_2,...

Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой.
А если все ключи во всех таблицах имеют название ID, то в какой-то момент можно подумать, что имеет смысл их сравнивать между собой.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996414
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimkas
Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой.

Вот это интересно в плане автоматизации построения запросов.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996426
Dimkas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
crutchmaster,
именно потребность в автоматизации построения запросов и породила решение

"знаешь идентификатор таблицы - знаешь о ней почти всё"
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996436
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей.

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

crutchmaster
Почему не делать все первичные поля id

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

Код: plsql
1.
c.client_id = s.client_id


оказываются существенно удобнее, нежели

Код: plsql
1.
c.id = s.client_id


, особенно в сложных запросах.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996592
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer
...

Код: plsql
1.
c.client_id = s.client_id


оказываются существенно удобнее, нежели

Код: plsql
1.
c.id = s.client_id


...

А мне кажется, что наоборот, второй вариант удобнее.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996616
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
и как тогда назвать первичный ключ у этой таблицы? client_privilege_id? как то заковыристо, на мой вкус
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996617
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorych
и как тогда назвать первичный ключ у этой таблицы?

Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996624
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно.
практика показывает обратное. Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа, в реальности, если рассматривать конкретный пример связи клиентов с действующими для них льготами, то, как минимум, нам потребуются ещё дата начала действия льготы, дата окончания действия льготы, ссылка на документ, на основании которого клиенту установлена эта льгота и т.д. Со всем этим придётся как-то взаимодействовать, и работать с id в такой таблице удобней, чем с составным ключом.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996626
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorych
Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа

В воспалённом воображении ЧАЛа всё должно иметь идентификатор, так что к нему близка как раз Ваша точка зрения. В остальном не вижу смысла здесь и с таким стартом тратить время на подобное обсуждение.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996632
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Использую следующие правила
1. Никакой транслитерации, только правильное английское название сущности,
.т.к. прочитает любой человек, будь то испанец или японец
2. Никаких сокращений, никому не интересно ломать голову, что это вы зашифровали в таблице,
а прежде всего вы сами быстро вспомните, что в этой таблице хранится.
3. В единственном числе, поскольку множественное число, как правило, в английском языке формируется добавлением -s,
помимо этого в английском языке есть исключения при формировании множественного числа, т.ч. отказавшись от множественного числа мы убираем лингвистические проблемы, и облегчаем себе всяческую автоматизацию.
4. Для отношений многие-ко-многим использую таблицы с названиями вида: BRANCH_STAFF
5. Для таблиц главная, подчинённая использую названия вида PATIENT ; PATIENT$SERVICE
6. Для всех таблиц (за исключением таблиц отношений многие-ко-многим) обязательно создаю первичный ключ с именем "Х"+"название таблицы", например в таблицах PATIENT и PATIENT$SERVICE будут соответственно первичные ключи XPATIENT и XPATIENT$SERVICE, для подчиненной таблицы будет ещё внешний ключ с названием первичного ключа главной таблицы, соответственно XPATIENT. Не использую для именования суффиксы-префиксы "_ID" , "ID", поскольку на мой взгляд они сильно засоряют запросы и замедляют восприятие текста. Проводил тестирование студентов, замедление восприятия текста около 20%.
Букву Х выбрал исходя из максимальной "бедности" этой буквы в английском языке.
7. В таблицах отношений многие-ко-многим присутствуют внешние ключи имеющие названия первичных ключей связываемых таблиц, например
Код: sql
1.
2.
3.
CREATE TABLE BRANCH_STAFF (
    XBRANCH   DX /* DX = INTEGER NOT NULL */,
    XSTAFF    DX /* DX = INTEGER NOT NULL */....
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996638
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zeon11
5. Для таблиц главная, подчинённая использую названия вида PATIENT ; PATIENT$SERVICE

Символ $ я предпочитаю зарезервировать для префикса. Когда количество таблиц в приложении переваливает за сотню и начинает бежать к тысячам, их алфавитная сортировка становится неудобной и список превращается в беспорядочную свалку. В этом случае здорово помогает введение промежуточного уровня иерархии, "группы таблиц", который я предпочитаю строить, добавляя префикс предметной области. Скажем, WH$SOMETHING - данные склада, а MAP$OTHERTHING - что-то, имеющее отношение к картам.

Конечно, для выражения подчинённости можно использовать другой символ, например, #, но я не ощущаю такой необходимости. Подчёркивание на этом месте вполне естественно и не создаёт проблем, хотя и выглядит сходно с развязками.

zeon11
6. Для всех таблиц (за исключением таблиц отношений многие-ко-многим) обязательно создаю первичный ключ с именем "Х"+"название таблицы"

Нарушаете логику пунктов 1-2.

zeon11
поскольку на мой взгляд они сильно засоряют запросы и замедляют восприятие текста. Проводил тестирование студентов, замедление восприятия текста около 20%.

Любопытно, что именно Вы называете "скоростью восприятия" и как её замеряли.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996653
Сотрудник Главного Управления
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrigoriyFomin
CLIENTS

Тоже не понимаю этой фигни.
Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе. Да и Microsoft рекомендует использовать множественное число, и все учебные БД от микрософта этот метод используют. В рекомендациях по проектированию REST API тоже советуют употреблять множественное число в адресах ресурсов.
Я вот всегда использую единственное число и никаких неудобств не ощущаю от этого.
...
Рейтинг: 0 / 0
подскажите хорошую практику наименования связанных таблиц
    #39996656
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сотрудник Главного Управления
Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе.

Это действительно чуть лучше с точки зрения восприятия текста. Одиночные значения называются в единственном числе, коллекции значений (в том числе таблицы) - во множественном, всё логично. В принципе, можно даже навесить определённое правило, мол подчинённая таблица называется CLIENT_PRIVILEGES (льготы клиента), а развязка называется CLIENTS_PRIVILEGES (клиенты - льготы).

Но эти соображения оказываются менее важными, чем удобства именования в единственном числе, в первую очередь автоматизм получения названия поля из названия таблицы.
...
Рейтинг: 0 / 0
25 сообщений из 132, страница 1 из 6
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / подскажите хорошую практику наименования связанных таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]