|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Доброго дня. Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы. Есть справочник клиентов CLIENTS, ключевое поле CLID, есть справочник льгот BENS, ключевое поле BNID и есть таблица со связью клиента и льгот. Как красиво ее назвать (таких троек таблиц будет много по разным сущностям), и как понятно назвать связывающую таблицу и ее поля (пара клиента и льготы)? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2020, 19:53 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
CLIENTS_BEANS CLID BNID Особо извращённые MS SQL пользователи могут использовать [Clients<->Bens]. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2020, 20:37 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Тогда надо алиасы таблиц указывать в запросе, так как поля имеют одинаковое название. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2020, 20:59 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin, Алиасы таблиц в запросах лучше указывать всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2020, 21:06 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin ... академическое красивое решение ... Нету такого. Каждый лепит от балды. Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2020, 23:39 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Злой Бобр GrigoriyFomin ... академическое красивое решение ... Нету такого. Каждый лепит от балды. Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним. А потом придет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма под одобряющее улюлюканье коллег по цеху, который будут предлагать свои решения ) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 00:12 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 00:29 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы Во-первых, справочник клиентов, как и другие таблицы, назвать в единственном числе - client. Во-вторых, его первичный ключ назвать client_id. В-третьих, справочнику льгот дать нормальное и подходящее по бизнес-логике название в единственном числе. Например, privilege. Его первичный ключ, соответственно, назвать privilege_id. В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 01:01 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика". мне 38, програмлю 25 лет, начиная с ZX Spectrum и я не слышал про базу болтика ) гугль тоже ничего не выдал. ЧЯДНТ! Я комплексую! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 01:38 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege. как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей. Так, справочник контрагентов CONTRAGENTS проще назвать CAS, сотрудников EMPS, ну и в таком роде. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 01:42 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
softwarer Во-вторых, его первичный ключ назвать client_id. И получится client.client_id. Зачем? Почему не делать все первичные поля id, а внешние - client_id. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 06:40 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin, У нас - так: первичный ключ - везде id, внешний ключ - fk_имя_таблицы, связанные таблицы table1xtable2, если совсем туго с именем. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 06:42 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
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.
Так вот в этом запросе есть два момента, которых лично мне хочется избежать: 1. Лишнее переименование d.name в department_name - хочется обойтись без переименования вообще. 2. Связь вида d_c.client_id = c.id - где связываемые поля имеют разные названия, хочется связывать поля с одинаковыми названиями. Поэтому у нас все таблицы, в которых хранятся сущности, имеют структуру вида client(idclient integer, client varchar, ...) и поля-ссылки на таблицу client всегда начинаются с idclient, И только если клиентов в одной таблице больше одного, то используем что-то типа idclient_1, idclient_2,... Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой. А если все ключи во всех таблицах имеют название ID, то в какой-то момент можно подумать, что имеет смысл их сравнивать между собой. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 07:56 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimkas Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой. Вот это интересно в плане автоматизации построения запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 08:39 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
crutchmaster, именно потребность в автоматизации построения запросов и породила решение "знаешь идентификатор таблицы - знаешь о ней почти всё" ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 09:25 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей. Как показывает опыт - бессмысленно учить того, кто даже не попытавшись начать думать, уверен, что всё знает лучше. Что же до сложности отладки, то она увеличивается не от длины названий, а от их кривизны. crutchmaster Почему не делать все первичные поля id Потому что никто не пользуется полными названиями таблиц как префиксами в запросах, а при коротких алиасах строчки типа Код: plsql 1.
оказываются существенно удобнее, нежели Код: plsql 1.
, особенно в сложных запросах. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 09:50 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
softwarer ... Код: plsql 1.
оказываются существенно удобнее, нежели Код: plsql 1.
... А мне кажется, что наоборот, второй вариант удобнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 14:44 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
softwarer В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:04 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
egorych и как тогда назвать первичный ключ у этой таблицы? Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:07 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
softwarer Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:19 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
egorych Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа В воспалённом воображении ЧАЛа всё должно иметь идентификатор, так что к нему близка как раз Ваша точка зрения. В остальном не вижу смысла здесь и с таким стартом тратить время на подобное обсуждение. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:22 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Использую следующие правила 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:39 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 5. Для таблиц главная, подчинённая использую названия вида PATIENT ; PATIENT$SERVICE Символ $ я предпочитаю зарезервировать для префикса. Когда количество таблиц в приложении переваливает за сотню и начинает бежать к тысячам, их алфавитная сортировка становится неудобной и список превращается в беспорядочную свалку. В этом случае здорово помогает введение промежуточного уровня иерархии, "группы таблиц", который я предпочитаю строить, добавляя префикс предметной области. Скажем, WH$SOMETHING - данные склада, а MAP$OTHERTHING - что-то, имеющее отношение к картам. Конечно, для выражения подчинённости можно использовать другой символ, например, #, но я не ощущаю такой необходимости. Подчёркивание на этом месте вполне естественно и не создаёт проблем, хотя и выглядит сходно с развязками. zeon11 6. Для всех таблиц (за исключением таблиц отношений многие-ко-многим) обязательно создаю первичный ключ с именем "Х"+"название таблицы" Нарушаете логику пунктов 1-2. zeon11 поскольку на мой взгляд они сильно засоряют запросы и замедляют восприятие текста. Проводил тестирование студентов, замедление восприятия текста около 20%. Любопытно, что именно Вы называете "скоростью восприятия" и как её замеряли. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 16:53 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
GrigoriyFomin CLIENTS Тоже не понимаю этой фигни. Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе. Да и Microsoft рекомендует использовать множественное число, и все учебные БД от микрософта этот метод используют. В рекомендациях по проектированию REST API тоже советуют употреблять множественное число в адресах ресурсов. Я вот всегда использую единственное число и никаких неудобств не ощущаю от этого. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 17:24 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Сотрудник Главного Управления Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе. Это действительно чуть лучше с точки зрения восприятия текста. Одиночные значения называются в единственном числе, коллекции значений (в том числе таблицы) - во множественном, всё логично. В принципе, можно даже навесить определённое правило, мол подчинённая таблица называется CLIENT_PRIVILEGES (льготы клиента), а развязка называется CLIENTS_PRIVILEGES (клиенты - льготы). Но эти соображения оказываются менее важными, чем удобства именования в единственном числе, в первую очередь автоматизм получения названия поля из названия таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2020, 17:28 |
|
|
start [/forum/topic.php?fid=32&msg=39996382&tid=1539838]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
2ms |
others: | 236ms |
total: | 404ms |
0 / 0 |