Как правильно называть таблицы в бд
«Всякое приказание должно быть отдано
в должное время, в должном месте,
и в выражениях, исключающих двоякое толкование»
(Из Устава Петровских времен)
Обсуждаемый вопрос заключается в следующем. Если мы начали разработку базы данных для некоторой задачи, определились с набором схем, таблиц, полей, внешних ключей, то как нам следует называть все эти объекты, и зачем вообще нужно говорить о какой-то особой системе наименований?
Проблема чем-то похожа на выбор имен для переменных при написании программного кода. Но разница в том, что в написании процедур мир давно уже пришел к идее локальных переменных, и их имена остаются на совести автора-программиста — согласуются только параметры вызова. А вот база данных — штука глобального характера. Имена таблиц и полей используются в процедурах обработки, в клиентских формах ввода, в отчетах. Стройная система имен позволит «протащить» логику организации данных сквозь весь проект, сделать все его части более читабельными, за что вы получите немало благодарностей как от коллег по команде, так и от себя лично, когда вернетесь к задаче эдак через полгодика. С другой стороны, полтысячи разношерстных огрызков вроде ‘trb_zrplt_mumu’, по десятку на одно и то же понятие, выведут из себя кого угодно.
- Единство именования программных единиц во всем проекте. Другими словами, если у нас есть, скажем «документ» (doc), или «номер документа» (docnum), то именно так должны называться таблица БД, ее соответствующее поле, соответствующие поля всевозможных VIEW, поля клиентских наборов данных, локальные переменные в процедурах обработки, классы, представляющие эту сущность на клиенте, поля (свойства) в этих классах, объекты во всех отчетах, и вообще все, что содержит в себе документ (номер). Другими словами, нельзя допускать размножения сущностей без необходимости. Нередко проектировщики свято соблюдают этот принцип Оккама при моделировании «внешних» данных, но напрочь игнорирую его во внутренней «кухне».
- Самодокументируемость структуры базы данных. Сформулировать это зыбкое понятие трудно, но без него работать еще труднее.
- Единообразие подачи информации пользователю. Если вернуться к тому же ‘номеру документа’, то с единством названия становится легче проследить и за единством подписей полей ввода, кнопок, шапок отчетов, содержащих этот реквизит, чтобы пользователь не терялся.
Выбор имени сущности
- Имя должно быть существительным (полным, сокращенным либо аббревиатурой) в единственном числе.
- Имя должно быть как можно короче. Оптимально — 2-4 буквы, максимум до 10.
- Имя должно быть уникальным в пределах базы данных.
- Имя должно быть мнемонически понятным проектантам без заглядывания в словарь (но словарь такой хорошо бы составить).
- Желательно, чтобы имена не начинались и не заканчивались на другие имена сущностей.
Нетрудно заметить, что все эти правила противоречат друг другу. И в инженерной практике это скорее правило, чем исключение. Чего стоит хотя бы идея плавающего танка. Так что придется выкручиваться.
Итак, почему как можно короче? Потому что на основании имени сущности мы будем «лепить» другие идентификаторы. Они будут встречаться целыми списками в секциях FROM, WHERE. И если названия таблицы и пяти соединенных справочников будут несокращенными словами в 16-20 символов, то это порадует лишь поклонников языка Шекспира, но успешно затуманит смысл простейших SQL-запросов.
Требование уникальности понятно само собой. Стоит лишь заметить, что здесь нужно максимально учесть перспективы роста БД. Возможно, стоит набросать список сущностей, которые могут войти в БД в следующих версиях системы, даже если эта работа отдаленного будущего.
Чтобы сделать имена понятными, нужно определиться — «salary» или «zarplata» ? То есть в качестве имен сущностей можно использовать английские слова и сокращения, либо русские (кстати, почему бы и не на других языках? Лишь бы. см. Правило 4 😉 Кстати, неплохо использовать комбинации из двух понятий. Например «группа пользователей» — «ugroup», «группа домов» — «hgroup».
Последнее, пятое правило говорит, что если у вас уже есть таблица ‘документ’ (doc), то для ‘докторов’ и ‘доктрин’ нужно выбрать что-то другое, а не ‘ doc tor’ и ‘ doc trine’. Океан тоже нехорошо называть ‘oc’ (иначе документ будет интуитивно восприниматься как нечто связанное с океаном — d oc ). Для решения такой проблемы можно изменить либо удлинить проблемный идентификатор, например ‘dcm’, ‘docum’,
Наименование таблиц
Многие проектировщики дают таблицам непосредственно имена сущностей (в единственном числе), например street, city. Другие же ратуют за то, что таблицы нужно называть множественным числом — streets, cities. И единого мнения быть не может. Дело в том, что если говорить об удобочитаемости SQL-запросов, вроде следующего:
SELECT * FROM cities, streets WHERE streets.cityid = cities.cityid AND streets.name LIKE "%тупик Третьего Интернационала%"
то нетрудно заметить, что секция FROM грамматически подразумевает множественное число — «ВЫБРАТЬ.. ИЗ городов, улиц «. В то же время секция WHERE «читается» с единственным числом — «ВЫБРАТЬ ту запись , ГДЕ название улицы ПОХОЖЕ . «, и это понятно — ведь условие под WHERE применяется к каждой записи набора по отдельности, то есть к каждой улице.
Если вспомнить, что мы хотим использовать имя сущности также в программах обработки данных, где объектом работы становится именно «единица» информации (например в названии класса для хранения одной улицы TStreet, а затем в названии переменой-объекта objStreet1), то разумнее остановиться на единственном числе как на стандарте. Но ведь в таблице все-таки живет множество сущностей! Как это выразить? Для таблиц примем следующее волюнтаристское решение:
Имя таблицы состоит из служебного префикса и имени сущности . Например.
| Префикс | Имя сущности | Имя таблицы | Название таблицы в целом (как множества сущностей) |
| C | STRTYPE (тип улицы) | C STRTYPE | Каталог типов улиц |
| S | STREET (улица) | S STREET | Справочник улиц |
| R | ABON (абонент) | R ABON | Реестр абонентов |
| J | CALCOP (выч. операция) | J CALCOP | Журнал вычислительных операций |
-
C — Catalog, список. Самая безобидная форма жизни информации. Представляет собой простейший справочник из десятка пунктов чего-то неизменного, или почти неизменного. Структурирует некую фундаментальную природу вещей. Например, перечисляет типы улиц — «улица», «переулок», «проезд», «тупик», «овраг». Через пару лет построят в деревне первый проспект — добавим «проспект».
Можно ввести дополнительные соглашения, приятные для программистов. Например, что записи из таблиц типа ‘C’ не удаляются, а только иногда добавляются. Что в интерфейсе для работы с таким списком будет достаточно унифицированной формы с полным просмотром содержимого и простейшим поиском-фильтром, а для выбора значения — выпадающего списка (ComboBox).
Не будем также забывать, что в качестве имен сущностей мы разрешили себе использовать сокращения и аббревиатуры. А в этом случае добавление «s» или «es» вряд ли добавит ясности и читабельности.
Будем считать, что с правилом именования таблиц мы определились. Разумеется, из любого правила есть исключения. Скажем, как именовать таблицы, отражающие связи «много-ко-многим»?, например вхождение пользователей (сущность user ) в группы (сущность ugroup )? Предлагаю использовать специальный префикс «nn_» , и получится nn_user_ugroup . Возможны и другие исключения.
Наименование полей
Имена полей таблицы, как правило, составляются из имени сущности ( city ), смыслового суффикса ( id, name, area ), и необязательного дополнительного суффикса (применяется для полей внешних ключей в случае множественных ссылок, рассмотрим это ниже). Например
| scity — Справочник городов | |
| cityid | Ид (PK) |
| city name | Название |
| city area | Площадь (км2) |
| city populcnt | Население |
| cstrtype — Список типов улиц | |
| strtypeid | Ид (PK) |
| strtype name | Название |
| sstreet — Справочник улиц городов | ||
| 1 | streetid | Ид (PK) |
| 2 | cityid | Город.Ид (FK scity ) |
| 3 | strtypeid | Тип улицы.Ид (FK cstrtype) |
| 4 | street name | Название |
В зале слышны крики ревнителей минимализма и экономии символов. Мы видим, что в имени каждого поля таблицы участвует название сущности, то есть практически повторяется имя таблицы (без префикса). Оправдано ли это? Почему бы всегда не называть идентификаторы просто ID , названия — Name ? Ведь в SQL-запросах есть возможность полной нотации имен, с указанием таблицы: WHERE scity.name LIKE «%МОСКВА%» AND sstreet.name LIKE «%ЛЕНИНА%» ?
Первое, на чем споткнется такой подход — внешние ключи. Пусть в списке типов улиц cstrtype ключ мы назвали ID , и ключ улицы тоже назвали ID . Как прикажете назвать поле номер 3 в таблице улиц sstreet , которое ссылается на тип улицы cstrtype ? Ах, вот теперь вы хотите назвать его strtype_id ? Но тогда получается, что в БД есть поля, содержащие одну и ту же информацию, а названные по-разному. Кто здесь хотел не плодить сущности без необходимости? Для единообразия придется вернуться в cstrtype , и переименовать тамошний ключ ID тоже в strtype_id . К той же печке и пританцевали.
Ну хорошо, не унимаются минималисты. С ключами понятно. А названия, и прочие неключевые поля? Их-то можно назвать просто Name?
Хорошо. Назовем названия города, улицы и типа улицы просто Name, и составим запрос, выводящий «Улица Ленина, Москва».
SELECT cstrtype.name, sstreet.name, scity.name. Хм. FROM scity, cstrtype, sstreet WHERE . связи между таблицами и условия поиска.
Три поля с одинаковыми названиями в результате запроса. Какое безобразие! Интересно, что на большинстве SQL-серверов ошибки выдано не будет, и строки данных будут правильны. Но имена столбцов! Некоторые SQL-сервера молча переименуют поля, вроде name_1, name_2, или name_a, name_b (кстати, я не припомню, чтобы порядок такого переименовывания где-то документировался). Другие издевательски вернут набор данных с тремя одинаковыми полями — типа вам из погреба виднее, разбирайтесь. Редкий ClientDataSet не выдаст Access Violation от такого зрелища, не говоря уже о безнадежности задачи FieldByName().
В этом месте обычно вспоминают о возможности SELECT cstrtype.name AS strtypename , долго сопят, размышляя о бритве Оккама, а затем лезут в поля таблиц дописывать имя сущности. Опять пританцевали.
Ну хорошо, умоляют последние минималисты. Обозначать принадлежность поля таблице надо. Но зачем же полное имя сущности повторять? Можно ведь сократить — ‘STName’, ‘StrName’, ‘CName’.
Нет, господа минималисты! Ведь зачем мы добавляем имя сущности в имя поля? Обеспечить уникальность полей в результатах запросов! А уникальность эта в общем виде должна работать в масштабах базы данных. Вот завтра выйдете на международный рынок, появится у вас понятие стран (Country), и имя страны как сократите — опять «CName»? Поэтому ставим вопрос ребром. Если вы можете сократить имя сущности до удобочитаемой и в то же время уникальной величины — так это сокращение и используйте изначально как имя сущности. Нет — используйте полное. Но везде одно и то же.
С именем сущности в составе названия поля вроде бы разобрались. А что там за смысловой префикс, все эти -id, -name, -label, -area ?
- id — внутренний идентификатор, суррогатный ключ. Автоинкрементный. От пользователя скрывается. Никогда не модифицируется.
- code — пользовательский идентификатор, уникальный ключ. Например, табельный номер сотрудника. Как правило, неизменный; но при необходимости его можно менять (когда у отдела кадров сносит крышу), причем без каскадных обновлений БД.
- name — имя чего-либо (скорее идентификатор, или нечто каноническое)
- label — название (обычно человеческое удобное название)
- notes — поле типа TEXT, для примечаний
- num — номер чего-либо (может быть числовой либо текстовый, например Письмо N «1234/56-789«)
- . разумеется, список можно продолжать.
Ставить ли подчеркивание между сущностью и смысловым суффиксом, вроде street_name — дело вкуса. Это красиво выглядит в статье, но отвратительно в программном коде, потому что в точечной нотации objStreet.Street_Name подчеркивание выглядит как разделитель более высокого уровня, чем точка, и сбивает с толку. Кроме того, подчеркивания плохо видны на некоторых шрифтах и на бумажных распечатках. Поэтому подчеркивания я использую редко. В Pascal достаточно придерживаться общепринятой венгерской нотации — начинать каждое слово с заглавной буквы: StreetName, а в SQL чаще всего пишут ключевые слова большими буквами, идентификаторы — в венгерской нотации или просто маленькими буквами.
Иногда в нескольких таблицах встречаются служебные поля, не связанные с какой-либо сущностью, а используемые программистом либо базой данных для служебных целей, например поля вроде Row_ID в Oracle. Здесь нужно следить, чтобы имена сущностей не пересекались с названиями таких полей, иначе служебные поля будут ошибочно «мысленно привязаны» к какой-то нашей таблице.
Множественные ссылки
Иногда в базах данных встречается ситуация, требующая дополнения описанных правил. Рассмотрим пример — точки и вектор, имеющий начало и конец:
| SPOINT — Справочник точек | |
| pointid | Ид |
| pointX | X |
| pointY | Y |
| pointName | Имя |
| pointColor | Цвет точки |
| SVECTOR — Справочник векторов | |
| vectorid | Ид |
| pointid_start | Начало (FK SPOINT ) |
| pointid_end | Конец (FK SPOINT ) |
| vectorColor | Цвет вектора |
В ситуации, когда из одной таблицы есть более одной ссылки на один и тот же справочник, приходится использовать дополнительный суффикс (_start, _end) в наименованиях полей-ссылок. Это тот редкий случай, когда я использую подчеркивание.
Кроме того, те же дополнительные суффиксы придется использовать и при переобозначении выходных полей запроса, если придется объединять оба экземпляра справочника. Например, выведем список векторов с указанием координат начала и конца:
SELECT vectorid, ps.pointX AS pointX_start, ps.pointY AS pointY_start, pe.pointX AS pointX_end, pe.pointY AS pointY_end FROM svector v, spoint ps, spoint pe WHERE v.pointid_start = ps.pointid AND v.pointid_end = pe.pointid
Другими словами, если справочник используется в двух вариантах (как _start и как _end), то мы должны быть готовы представить все его данные в этих двух вариантах одновременно добавлением соответствующих дополнительных суффиксов к именам полей, а для пользователя — добавлением слов «Начало», «Конец» к стандартным наименованиям шапок отчета.
Коварство ситуации заключается в том, что помимо очевидного случая (две ссылки из одной таблицы на другую), мы можем прийти к той же проблеме на внешне благополучной схеме БД, если, начав путешествие из какой-либо таблицы по стрелкам внешних ключей, имеем возможность попасть в какой-либо справочник более чем одним путем. Если в каком-либо запросе мы захотим объединения всех промежуточных таблиц, опять придется разруливать варианты справочника.
Небольшое замечание. Если в процессе проектирования наклевывается ситуация с множественными ссылками, особенно более чем в двух вариантах — проверьте, не лучше ли заменить эту схему таблицей один-то-многим. Например, если у города есть руководитель мэрии, и председатель обкома партии:
| SCITY — справочник городов | |
| cityid | |
| manid_mer | FK sman — люди |
| manid_partyboss | FK sman- люди |
| . | |
то это можно выразить иначе:
| SCITY- справочник городов | |
| cityid | |
| . | |
| SBOSS — справочник начальников (один город — много начальников) | |
| bossid | |
| cityid | FK scity |
| bstypeid | FK cbstype — виды начальников |
| manid | FK sman — люди |
и дополнительный справочник, отражающий, в сущности, понятия _mer и _partyboss первоначального варианта:
| CBSTYPE — виды начальников | |
| bstype id | |
| bstypename | Название (мэр, партийный лидер и т.д.) |
Когда же разумно применять такое преобразование? Например, трудно представить себе, что у вектора появится третья вершина, или что у бухгалтерской проводки появится что-то кроме дебета и кредита — следовательно, таблица 1-N не нужна. А вот новые начальники в городе могут появиться запросто — например, военный комендант, если произойдет военный переворот, и командир партизанского военного округа, возглавляющий ему сопротивление. Баррикады, стрельба, переделка структуры БД. А с 1-N таблицей нам и структуру базы данных менять не надо, только дополнить справочник CBSTYPE!
Другие объекты базы данных
- Первичные ключи называем так: PK_имя_таблицы.
- Уникальные: UN_имя_таблицы_имена_всех_полей (если хватит терпения и допустимой длины), или просто UN_имя_тфблицы_номер_ключа_по_порядку.
- Внешние ключи: FK_имя_таблицы_имя_поля_ссылки_имя_таблицы-справочника
Указанные правила выглядят более естественно при выполнении некоторых дополнительных условий, которые выходят за рамки проблемы наименования, но о которых стоит упомянуть. Как вы уже заметили, в рассмотренных примерах в каждой таблице есть первичный ключ, причем ключ суррогатный. В этом вопросе я являюсь поклонником мнения Анатолия Тенцера, высказанного в статье «Естественные ключи против искусственных ключей». Лучше всего, когда в первичном ключе всего одно поле. Разумные дополнения к этому правилу — это территориально распределенные базы данных, где в первичном ключе участвует еще одно поле — идентификатор узла БД, уже упоминавшиеся таблицы «много-ко-многим» (nn_), и различные реализации времязависимых таблиц с указанием сроков действия каждой записи — эти реквизиты тоже участвуют в PK.
Еще один вопрос, который напрашивается после «упорядочения» названий в БД — как автоматизировать использование этого богатства? У нас есть названия сущностей, в том числе с русской расшифровкой, названия и русская расшифровка названий полей — нельзя ли сохранить эту информацию в БД и использовать ее непосредственно в программе, ее диалогах, фильтрах, отчетах, независимо используемых компонентов и языков? К сожалению, не существует общепринятого способа сохранения таких метаданных для использования различными средами разработки. Все движения в этом направлении намертво завязаны на конкретные продукты (Репозиторий в Delphi, системный словарь в PowerBuilder, конфигуратор в 1C, метаданные в Visual FoxPro), и все они обладают определенными ограничениями и неудобствами. Так что здесь есть о чем помечтать.
Yii Framework
В разных модулях и примерах по-разному называются таблицы и поля.
Мне кажется логичным называть таблицы также, как модель, с большой буквы: Product, PriceDescription. А поля также, как свойства модели: userId, userName.
Однако, все миграции, что я производил, создают такое: price_description и т.д., поля везде по-разному называются. Есть ли какой-то ПСР по этом вопросу?
Bio man Сообщения: 609 Зарегистрирован: 2013.07.22, 10:40
Re: Правильный нейминг таблиц и полей MySQL
Сообщение Bio man » 2015.07.20, 15:33
Стандарта не встречал, но вроде-как большинство пользуется такой записью:
Таблицы — post_author
Поля — user_id
Да и Gii так устроен, что имя таблицы post_author преобразует в название модели PostAuthor.
И еще 1 рекомендация, таблицы называть в единственном числе, что бы автоматически сгенерированое имя модели было тоже в единственном числе.
Лично я предпочитаю идти по пути yii для однообразия, да и привычно так.
nepster Сообщения: 838 Зарегистрирован: 2013.01.02, 03:35
Re: Правильный нейминг таблиц и полей MySQL
Сообщение nepster » 2015.07.20, 17:27
не знаю я считаю тупняковым называть таблицу в единственном числе. Поэтому называю примерно так:
Posts — таблица
Post — модель
Вместо id post_id, это вам потом поможет в том, что будет меньше ошибок типа: ambiguous
Поля в базе данных: user_id
Название переменных: $userId
unclead Сообщения: 160 Зарегистрирован: 2015.03.13, 19:44
Re: Правильный нейминг таблиц и полей MySQL
Сообщение unclead » 2015.07.20, 18:57
Стандартов нет, главное выбрать свой и следовать на протяжении всего проекта.
Я встречал как и таблицы во множественном числе, так и в единственном.
вот вырезка из доки по уии1
Большинство приложений хранят данные в БД. Мы предлагаем соглашения для именования таблиц и их полей. Стоит отметить, что Yii не требует строгого следования этим правилам.
Таблицы и поля именуются в нижнем регистре.
Слова в названиях разделяются символом подчёркивания (например, product_order).
В именах таблиц используется либо единственное число, либо множественное, но не оба сразу. Мы рекомендуем использовать единственное число.
Имена таблиц могут содержать префикс. Например, tbl_. Это особенно полезно, когда таблицы нашего приложения находятся в БД, используемой одновременно другими приложениями.
SQL, соглашение об именовании таблиц
хотел спросить про соглашение об именовании в SQL в частности таблиц. Они должны быть с маленькой буквы написаны или с большой? Есть ли разница? Интересно еще как для PostgreSQL.
Отслеживать
задан 23 сен 2019 в 13:33
Mike Mclaren Mike Mclaren
835 12 12 серебряных знаков 24 24 бронзовых знака
соглашение об именовании в SQL в частности таблиц. Они должны быть с маленькой буквы написаны или с большой? Во всех примерах в PostgreSQL Documentation все имена (баз, таблиц, полей и пр.) пишутся исключительно в нижнем регистре. Есть ли разница? Иногда есть (если квотировано), иначе нет. См. Lexical Structure — Identifiers and Key Words
Как правильно называть таблицы в бд
Здравтвуйте уважаемые знатоки))
Читал я недавно книжку по C# и наткунулся на интересную главу,
в которой описываются некоторые правила именнования объектов в базе данных,
допустим нужно называть таблицу с продуктами Product, а не Products.
Вообщем я стал лазит в просторах инета, искать что-то более интересное и подробное, натыкался на примерно вот такое http://www.citforum.ru/database/articles/naming_rule/.
Есть какая-нибудь спецификация? Кто как имеенует объекты в базе? Сколько в своей жизни не видел баз, в каждой по разному именуется.
Re: Правила именования объектов базы данных
| От: | Lexxpin |
| Дата: | 02.03.10 10:15 |
| Оценка: |
ACD>Есть какая-нибудь спецификация? Кто как имеенует объекты в базе? Сколько в своей жизни не видел баз, в каждой по разному именуется.
Каждый именует как хочет.
Я придерживуюсь следующих аналогий:
1) схема — пространство имен
2) таблица — класс
3) колонка — свойство
и т.д.
Соответственно, какие правила существуют в ЯП такие и в БД.
Такие правила мне кажется удобными при автоматической генерации кода по БД.
Re[2]: Правила именования объектов базы данных
| От: | AC1D |
| Дата: | 02.03.10 10:31 |
| Оценка: |
Здравствуйте, Lexxpin, Вы писали:
ACD>>Есть какая-нибудь спецификация? Кто как имеенует объекты в базе? Сколько в своей жизни не видел баз, в каждой по разному именуется.
L>Каждый именует как хочет.
L>Я придерживуюсь следующих аналогий:
L>1) схема — пространство имен
Насколько я помню простарансво имен нужно называть использую название фирмы или компании и отдела?
Неужели у вас назаваеться схемы называются Vasja_Pupkin_I_KO или Acme?
Не микросовтовских баз, не ораклиных, не IBM со схемами Microsoft,IBM и Oracle я не припомню)
L>2) таблица — класс
L>3) колонка — свойство
L>и т.д.
L>Соответственно, какие правила существуют в ЯП такие и в БД.
L>Такие правила мне кажется удобными при автоматической генерации кода по БД.
Правила другие, возможно у них есть что-то общее: например называть таблицу по имени сущности которою она хранит, для повышения удобочитаемости
Re: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 02.03.10 10:43 | |
| Оценка: | +1 | |
Здравствуйте, AC1D, Вы писали:
ACD>допустим нужно называть таблицу с продуктами Product, а не Products.
А я читал спецификацию где советуют именно Products; объясняя поведение оппонентов желанием натянуть ООП на РБД. Дальше красиво расписывают что ООП туда не влезет никак, даж приводят ссылки на известных и важных людей. Я считаю что надо называть всё своими именами, если таблица со списком изделий, то и название должно быть «список изделий»=ProductList или «изделия»=Products. Потому что в таких выкрутасах можно уйти так далеко, что в собственном коде придётся разбираться много долше, чем ушло на его написание.
ACD>Вообщем я стал лазит в просторах инета, искать что-то более интересное и подробное, натыкался на примерно вот такое http://www.citforum.ru/database/articles/naming_rule/.
При беглом взгляде нашёл больше вредных советов, чем полезных.
ACD>Есть какая-нибудь спецификация? Кто как имеенует объекты в базе? Сколько в своей жизни не видел баз, в каждой по разному именуется.
У каждого своя, как уже сказал Lexxpin. Спецификаций много, разных и больших. Одной мессагой в форуме это не описать.
————-
РБД = реляционные базы данных
ООП = ты не знаешь что такое ООП!? 😉
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re: Правила именования объектов базы данных
| От: | Lexxpin | |
| Дата: | 02.03.10 10:52 | |
| Оценка: | 1 (1) | |
Хороших рекомендаций можно найти уйму, вот плохие рекомендации всегда одни и те же
Re[3]: Правила именования объектов базы данных
| От: | AC1D |
| Дата: | 02.03.10 11:01 |
| Оценка: |
Сорри за корявый перевод, переводил Google переводчик )
Всех объектов базы данных
* Ограничьте имя до 30 символов (чем короче, тем лучше)
* Используйте только буквы или символы подчеркивания (старайтесь избегать цифр)
* Попробуйте использовать символы подчеркивания как можно меньше. PascalCase обозначения достигает того же разделения слов и без них.
* Используйте письма в качестве первого символа имени. (не запускать имена с подчеркиванием)
* Избегайте сокращений (может привести к неправильному толкованию названия)
* Избегайте сокращений (в некоторых сокращенных иметь более одного значения, например. «ASP»)
* Делает имя читаемым (они не должны звучать смешно, когда читал вслух)
* Старайтесь не использовать пробелы в именах, даже если система позволяет это сделать.
Правило 1a (Многофигурные мена) — Таблица имена должны быть множественном числе, например, «клиенты» вместо «клиент». Это правило применимо, поскольку таблицы являются логическим коллекции из одного или более лицами в виде записей — как сбор классов логических коллекций одного или нескольких объектов. Если вы были первым делом обращают абстрактной модели данных, такие как Ниам / ORM модели может иметь особые имени лицом, как «Клиент» или «пользователь», но они должны быть изменены в форме множественного числа при построении фактической таблиц. Для таблицы имен с несколькими словами, только последнее слово должно быть множественное число, например, «UserRoles» и «UserRoleSettings».
Вот кстати в книге я читал наоборот совет, надо делать Client вместо Clients
Правило 1B (префиксы) — используется правильно, таблица префиксов могут помочь вам организовать вашу таблицах по соответствующим группам или отличить их от других связанных таблиц. Б плохо, они могут причинить вам придется вводить много ненужных символов. Мы обсудим, чего не следует делать в первую очередь. Не давать имена таблиц префиксов, как «табло» или «TBL_», это просто излишне и ненужно.
Вот как раз мой случай, теперь думаю: зачем я в базе из 5 таблиц понаставил TBL везде , ведь там вообще кроме таблиц нечего нет
В некоторых случаях, таблицы может быть обмен схеме / базы данных с другими таблицами, которые не связаны каким-либо образом. В этом случае, иногда неплохо использовать префиксы имен таблиц с некоторыми символами, что и группа таблиц. Например, для медицинского применения вы можете дать вашим таблиц «ХК» префикс, чтобы все таблицы для этого приложения будет появляться в алфавитный список вместе.
Правило 1C (обозначения) — для всех частей имя таблицы, включая префикс, используя PascalCase. Использование этих обозначений будет отличать собственные имена таблиц с SQL ключевыми словами (все заглавные буквы). Например, «SELECT CustomerId_Pk, CustomerName FROM MyAppGroupTable WHERE CustomerName = ‘%S'» показывает обозначение имя таблицы, отличающие его от SQL ключевых слов, используемых в запросе. PascalCase также снижает необходимость подчеркивания.
Re[2]: Правила именования объектов базы данных
| От: | AC1D |
| Дата: | 02.03.10 11:10 |
| Оценка: |
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Здравствуйте, AC1D, Вы писали:
ACD>>допустим нужно называть таблицу с продуктами Product, а не Products.
ZAM>А я читал спецификацию где советуют именно Products; объясняя поведение оппонентов желанием натянуть ООП на РБД. Дальше красиво расписывают что ООП туда не влезет никак, даж приводят ссылки на известных и важных людей. Я считаю что надо называть всё своими именами, если таблица со списком изделий, то и название должно быть «список изделий»=ProductList или «изделия»=Products. Потому что в таких выкрутасах можно уйти так далеко, что в собственном коде придётся разбираться много долше, чем ушло на его написание.
А эти мотивировали не грамотностью, покажи мне серийный_номер продукта где /> а не покажи мне серийный номер продуктов
ACD>>Вообщем я стал лазит в просторах инета, искать что-то более интересное и подробное, натыкался на примерно вот такое http://www.citforum.ru/database/articles/naming_rule/.
ZAM>При беглом взгляде нашёл больше вредных советов, чем полезных.
Да я просто привел, как пример
Re[3]: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 02.03.10 13:13 | |
| Оценка: |
Здравствуйте, AC1D, Вы писали:
ACD>А эти мотивировали не грамотностью, покажи мне серийный_номер продукта где >
ACD>а не покажи мне серийный номер продуктов
«Покажи мне серийный_номер, из таблицы продуктов, где и правильно это писать так:
SELECT p.SerialNum FROM Products AS p WHERE p.ID = 5А в структуре БД из-за «кривых названий», очень муторно ковыряться. Причём реально муторно не сразу, а когда база стала достаточно большой и что-то менять в ней нет ни времени ни сил!
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re: Правила именования объектов базы данных
| От: | cvoronin |
| Дата: | 02.03.10 18:33 |
| Оценка: |
ACD>Есть какая-нибудь спецификация? Кто как имеенует объекты в базе? Сколько в своей жизни не видел баз, в каждой по разному именуется.
Использование единственного или множественного числа зависит ещё и от стиля проектирования.
В классических ER-моделях сущности (и, почти автоматически, вслед за ними и таблицы) именовались именно в единственном числе, чтобы упростить чтение связей между ними — один Киллер имеет несколько Пистолет(ов) и ноль-или-один Заказ(ов). Как видно, косяки со множественным числом вылазили и в этом случае, но оно было более управляемо.
Подход с использованием множественного числа имеет, имхо, более прагматичные истоки — в одной таблице много записей-то, так и назвать их Клиенты тогда логично.
Мы в своих проектах пользуем единственное число, пре- и суффиксы для обозначения таблиц (разумеется) не используем.
Хоть некто Джо Селко и называет ламерством использование специальных обозначений для представлений, я эти спец обозначения люблю — потому как видно, что V_CLIENT суть представление и работать с ним, возможно, надо по-другому.
На самом деле, особой разницы в единственном или во множественном числе нет — главное, чтобы в одном проекте не смешивались бы разные стили.
Опять же со старых времён осталась привычка называть объекты БД БОЛЬШИМИ буквами, при необходимости РАЗДЕЛЯЕМ_ВОТ_ТАК.
Такой же стиль — Vasja_Pupkin_I_KО, т. е. одновременное использование CamelCase и разделителей — имхо, не есть красиво.
Re[4]: Правила именования объектов базы данных
| От: | . |
| Дата: | 02.03.10 22:22 |
| Оценка: |
On 02/03/2010 13:01, AC1D wrote:
> PascalCase обозначения
Вот это, конечно, я тоже люблю, но возникают с этим технические проблемы. Скажем, постгрес не сохраняет регистр букв, и если создать таблицу с именем PascalCase, то реально будет создано PASCALCASE, и становится нечитабельным. Так что для имён в субд приходится использовать uderscore_naming, ибо UNDERSORE_NAMING хотя бы не так плохо выглядит.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 03.03.10 08:16 | |
| Оценка: | 1 (1) | |
Здравствуйте, ., Вы писали:
.>Вот это, конечно, я тоже люблю, но возникают с этим технические проблемы.
Поэтому я всегда скептически отношусь к статьям типа «Правила программирования на SQL!», т.к. правила программирования на «всём» SQL — это попытка натянуть презерватив на глобус. Есть конечно множество общих положений (даже и не только для SQL общих), но нюансов каждого движка БД и ограничений/возможностей административных инструментов этой же БД нельзя ни учитывать (и нельзя учесть для «всех»). Правила надо формировать для конкретного движка SQL, и не разрешать себе попытки сделать их похожими на правила программирования в чём-то другом, руководствуясь фразой «так привычнее».
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re[2]: Правила именования объектов базы данных
| От: | Ziaw |
| Дата: | 03.03.10 08:48 |
| Оценка: |
Здравствуйте, cvoronin, Вы писали:
C>Хоть некто Джо Селко и называет ламерством использование специальных обозначений для представлений, я эти спец обозначения люблю — потому как видно, что V_CLIENT суть представление и работать с ним, возможно, надо по-другому.
А по факту при таких префиксах начинаются проблемы с рефакторингом table to view. Тут приходится либо отступить от правила, либо потерять большую часть пользы от рефакторинга.
C>На самом деле, особой разницы в единственном или во множественном числе нет — главное, чтобы в одном проекте не смешивались бы разные стили.
+1
C>Опять же со старых времён осталась привычка называть объекты БД БОЛЬШИМИ буквами, при необходимости РАЗДЕЛЯЕМ_ВОТ_ТАК.
C>Такой же стиль — Vasja_Pupkin_I_KО, т. е. одновременное использование CamelCase и разделителей — имхо, не есть красиво.
Это еще от БД зависит, в Оракле, например, объекты либо создаются в верхнем регистре и тогда они регистронезависимы, либо смешанном регистре в кавычках, но тогда к ним придется обращаться только как
select count(*) from "CamelCase"select count(*) from сamelсase; select count(*) from CamelCase;не найдут таблицу, поскольку будут эквивалентны
select count(*) from "CAMELCASE";Соответственно если нет желания ловить ошибки регистра там лучше придерживаться underscore разделения, имхо это меньшее зло.
Re[6]: Правила именования объектов базы данных
| От: | . |
| Дата: | 03.03.10 09:23 |
| Оценка: |
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Поэтому я всегда скептически отношусь к статьям типа «Правила программирования на SQL!», т.к. правила программирования на «всём» SQL — это попытка натянуть презерватив на глобус. Есть конечно множество общих положений (даже и не только для SQL общих), но нюансов каждого движка БД и ограничений/возможностей административных инструментов этой же БД нельзя ни учитывать (и нельзя учесть для «всех»). Правила надо формировать для конкретного движка SQL, и не разрешать себе попытки сделать их похожими на правила программирования в чём-то другом, руководствуясь фразой «так привычнее».
С конкретным движком тоже не всё просто. Если есть хибернейт, который маппится на разные БД, то становится всё плохо. Есть куча движков, и хочется правила одинаково хорошо (плохо) работающие везде.
Особенно всё плохо с ключевыми словами. Работало «system_user» с одной СУБД, и вдруг перестало, т.к. в какой-нибудь Дербе оно вдруг ключевое слово.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 03.03.10 09:23 | |
| Оценка: |
Здравствуйте, Ziaw, Вы писали:
Z>А по факту при таких префиксах начинаются проблемы с рефакторингом table to view. Тут приходится либо отступить от правила, либо потерять большую часть пользы от рефакторинга.
А по мне уж лучше 10 минут потратить на замену имени V_CLIENT на CLIENT в зависимых запросах, чем красноглазить в рассматривании Execution Plan’а запроса тормозящего из-за того, что одна из таблиц на самом деле представление из трёх пяти таблиц с группировкой и прочими радостями.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re[7]: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 03.03.10 12:22 | |
| Оценка: |
Здравствуйте, ., Вы писали:
.>С конкретным движком тоже не всё просто. Если есть хибернейт, который маппится на разные БД, то становится всё плохо. Есть куча движков, и хочется правила одинаково хорошо (плохо) работающие везде.
Понимаю, мне тоже прохалявить хочется и хочется натянуть презерватив на глобус, но обычно получается что чем больше прохалявишь в начале, тем больше прийдётся пахать потом; а презерватив рвётся в районе Индийского океана. 🙂
Вообще, я слабо понимаю зачем нужно много разных СУБД в работе. Если только это не старые какие-нить проекты с которых конвертировать надо, и поддерживать их трупы в относительно живом виде, так там ничего не надо проектировать! . ну мож для конвертеров поля и ключами из других баз добавить. Ну а если ты DBA, то IMHO такая уж твоя работа, не нравится что она такая трудная — ищи другую.
.>Особенно всё плохо с ключевыми словами. Работало «system_user» с одной СУБД, и вдруг перестало, т.к. в какой-нибудь Дербе оно вдруг ключевое слово.
Бывает. 🙂
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re[8]: Правила именования объектов базы данных
| От: | . |
| Дата: | 03.03.10 12:28 |
| Оценка: |
On 03/03/2010 14:22, ZAMUNDA wrote:
> Вообще, я слабо понимаю зачем нужно много разных СУБД в работе. Если
Например, какая-нибудь система багтрекерная, которую юзеры себе ставят, используя СУБД какую хотят.
Или у нас — на сервере полноценная Postgres, а у клиентов embedded H2.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Правила именования объектов базы данных
| От: | cvoronin |
| Дата: | 03.03.10 14:19 |
| Оценка: |
C>>Хоть некто Джо Селко и называет ламерством использование специальных обозначений для представлений, я эти спец обозначения люблю — потому как видно, что V_CLIENT суть представление и работать с ним, возможно, надо по-другому.
Z>А по факту при таких префиксах начинаются проблемы с рефакторингом table to view. Тут приходится либо отступить от правила, либо потерять большую часть пользы от рефакторинга.
Есть такое. С другой стороны, зная, что работаю именно с представлением, лишний раз посмотрю — а в какие поля изменения вносить можно? А какие поля из другой таблицы приплыли и трогать их не надо?
Re[4]: Правила именования объектов базы данных
| От: | Ziaw |
| Дата: | 05.03.10 07:27 |
| Оценка: |
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>А по мне уж лучше 10 минут потратить на замену имени V_CLIENT на CLIENT в зависимых запросах
А зачем тогда вообще такой рефакторинг? Если за 10 минут можно во всех местах поменять все что нужно, от него вреда будет едва ли не больше чем пользы.
Re[4]: Правила именования объектов базы данных
| От: | Ziaw |
| Дата: | 05.03.10 07:30 |
| Оценка: |
Здравствуйте, cvoronin, Вы писали:
C>Есть такое. С другой стороны, зная, что работаю именно с представлением, лишний раз посмотрю — а в какие поля изменения вносить можно? А какие поля из другой таблицы приплыли и трогать их не надо?
Что значит вносить изменения в поля? Изменение данных? Такой рефакторинг предполагает полную эмуляцию таблицы. Изменение схемы? При таком изменении можно и без префикса догадаться, что это вьюха.
Re[5]: Правила именования объектов базы данных
| От: | ZAMUNDA | для жалоб и предложений |
| Дата: | 05.03.10 11:11 | |
| Оценка: |
Здравствуйте, Ziaw, Вы писали:
ZAM>>А по мне уж лучше 10 минут потратить на замену имени V_CLIENT на CLIENT в зависимых запросах
Z>А зачем тогда вообще такой рефакторинг? Если за 10 минут можно во всех местах поменять все что нужно, от него вреда будет едва ли не больше чем пользы.
Я что-то запутался, так вы за имя «V_CLIENT» или «CLIENT» у представления? Конечно очень редко приходится представление в таблицу переделывать, поэтому лучше написать «V_CLIENT» чтоб в запросах всегда видеть что это именно представление; а переименовывать его в таблицу придётся очень врядли, и поэтому проблем с рефакторингом можно не боятся. Реально, чаще не представление в таблицу, а наоборот таблицу в представление приходится переделывать. Если структура БД изменяется, то чтоб на новой структуре БД работало старое клиентское ПО, приходится делать подобные выкрутасы. Но только если это старое ПО, которое или невозможно/сложно/ненужно переделывать. А рабочее ПО, ОБЯЗАТЕЛЬНО надо подвергать рефакторингу, в таких случаях; причём, по-возможности, не заменять имя таблицы на представление («V» в имя добавлять), а переписывать запросы на работу с новой структурой. Потомучто в итоге, рано или поздно, сложность базы достигнет критического уровня — и после этого рефакторинг станет невозможен, т.е. проект умрёт. И, что самое страшное, смерти будет предшествовать долгая и мучительная болезнь — которая порвёт не один метр ваших нервов.