Именование таблиц: подчеркивание против Camelcase? пространства имен? Единственное или множественное число?

89

Я читал пару вопросов / ответов о StackOverflow, пытаясь найти «лучший», или я должен сказать, должен быть принятый способ именования таблиц в базе данных.

Большинство разработчиков склонны называть таблицы в зависимости от языка, на котором требуется база данных (JAVA, .NET, PHP и т. Д.). Однако я просто чувствую, что это неправильно.

То, как я до сих пор именовал таблицы, делает что-то вроде:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

Меня беспокоят следующие вещи:

  • Разборчивость
  • Быстрое определение модуля, в котором находится таблица (врачи || пациенты)
  • Легко понять, чтобы не возникало недоразумений.

Я хотел бы прочитать любые мнения относительно соглашений об именах. Спасибо.

database  database-design 
— Марио Рикальде
источник

Ответы:

180

Постоянство гораздо важнее, чем то, какую конкретную схему вы используете.

— Дэвид Онейл
источник
21
Другими словами, да, молодцы, вы определили несколько последовательных схем. Ладить с ней!
— Phil H
3
+1 за комментарий. Кроме того, в качестве примечания к текущей схеме именования PascalCase лучше, особенно если вы не используете псевдонимы для SQL-запросов. Таким образом, вы можете просто использовать camelcase в именах столбцов таблицы и Pascal Case в именах таблиц.
— MarioRicalde
3
Регистр Pascal / camel для имен таблиц может привести к некоторым проблемам. Каждая таблица будет иметь файл в файловой системе, и некоторые из них нечувствительны к регистру (например, OSX).
— ismriv
2
@ismriv, это проблема только в том случае, если вы непоследовательны, если вы всегда ссылаетесь на таблицы / представления / столбцы с одним и тем же последовательным регистром, у вас не должно быть никаких проблем, не ленившись при написании этих имен, вы получите большой преимущество позже при чтении. Использование PascalCase для таблиц и camelCase для столбцов помогает с первого взгляда определить тип имени, а также имитирует общие соглашения об объектно-ориентированной архитектуре.
— TWiStErRob
Я полностью согласен , что последовательность является ключевой, но это старый вопрос , и для людей , использующих новые платформы баз данных , как Redshift и Снежинка , которые по умолчанию для идентификаторов либо всех верхнего или нижнего регистра, я хотел бы добавить , что это очень важно думать о вашем соглашения об именах с самого начала. Использование соглашения об именах, например Camel Case, на этих платформах может вызвать у вас некоторые ненужные головные боли в дальнейшем, например, вам придется все время использовать цитируемые идентификаторы, а разрешение имен объектов может привести к неожиданным результатам.
— Натан Гриффитс,
22

Я обычно использую PascalCase, и сущности уникальны:

DoctorMain
DoctorProfile
DoctorPatient

Он имитирует соглашения об именах для классов в моем приложении, сохраняя все аккуратно, чисто, согласованно и легко для всех.

— Джастин Нисснер
источник
3
Да ... да, верю. Сегодня утром у меня немного туманно. Внесение правки ... спасибо.
— Джастин Нисснер,
3
Он также известен как «CapitalCase».
— corsiKa
3
Я никогда не слышал, чтобы это называлось "CapitalCase" за свой 30-летний опыт. Я слышал, что это чаще всего называют «верблюжьим делом», а в последнее время им стали заниматься «дело Паскаля». Я пришел сюда, чтобы понять, почему люди, похоже, используют верблюжий регистр для SQL, когда исторически он в основном не учитывал регистр. Я, конечно, не хочу отставать от времени.
— Sinthia V
@SinthiaV Я не знаю о других, но в нашем случае, поскольку мы используем JS ORM (к сожалению), варианты были: 1) нарушить соглашение с использованием camelCase в db 2) нарушить соглашение с помощью snake_case в JS 3) map camelCase в JS в snake_case в db. Мы решили без особой первоначальной мысли использовать camelCase в базе данных, и это было неплохо, но цитировать все немного затруднительно.
— Энди
@SinthiaV как бесполезный комментарий, это может быть в контексте фактического вопроса SO, PascalCase не то же самое, что camelCase. PascalCase делает первую букву каждого слова заглавной (особенно в том числе и первое), тогда как camelCase делает заглавными только слова после первого. Дальнейшее чтение: medium.com/better-programming/...
— страньше
11

Поддержка SQL без учета регистра Underscores_Scheme. Однако современное программное обеспечение поддерживает любую схему именования. Однако иногда некоторые неприятные баги, ошибки или человеческий фактор могут привести к UPPERCASINGEVERYTHINGтому, что те, кто выбрал и то, Pascal_Caseи другое Underscore_Case, живут всеми своими нервами в хорошем месте.

— terR0Q
источник
10

Совокупность большинства из вышеперечисленного:

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

Затем вы можете легко (даже автоматически) переводить имена между средами.

Но я бы добавил еще одно соображение: вы можете обнаружить, что при переходе от класса в своем приложении к таблице в базе данных есть другие факторы: объект базы данных имеет представления, триггеры, сохраненные процессы, индексы, ограничения и т. Д. также нужны имена. Так, например, вы можете обнаружить, что обращаетесь к таблицам только через представления, которые обычно представляют собой простой "select * from foo". Они могут быть идентифицированы как имя таблицы с суффиксом «_v» или вы можете поместить их в другую схему. Цель такого простого уровня абстракции состоит в том, что он может быть расширен при необходимости, чтобы разрешить изменения в одной среде, чтобы избежать влияния на другую. Это не нарушит приведенные выше предложения по именованию - нужно учитывать еще несколько вещей.

— KenFar
источник
8

Я использую подчеркивания. Несколько лет назад я работал над проектом Oracle, и мне показалось, что Oracle перевел все имена моих объектов в верхний регистр, что нарушает любую схему корпуса. Я на самом деле не специалист по Oracle, так что, возможно, был способ обойти это, о котором я не знал, но он заставил меня использовать подчеркивания, и я никогда не возвращался.

— Рэй
источник
2
В версиях 11g и выше регистр сохраняется, если имя таблицы заключено в двойные кавычки. Поместите это здесь для использования в будущем. Я точно знаю, что Postgres делает то же самое, другие движки db - нет.
— John O
8

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

/ [a-z _] [a-z0-9 _] * / на самом деле единственный шаблон имен, который легко переводится между разными платформами. Буквенно-цифровые символы в нижнем регистре + нижнее подчеркивание всегда работают одинаково.

Как упоминалось в другом месте, имена отношений (таблиц) должны быть единственными: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

— богатый Ремер
источник
Я согласен - подчеркивание имеет меньше всего проблем по сравнению с Pascal или camel Casing. Особенно, когда вы в конце концов перейдете к моделям, dto и интерфейсу.
— Saulius
6

Я склонен согласиться с людьми, которые говорят, что это зависит от используемых вами соглашений (например, PascalCase для C # и snake_case для Ruby).

Однако никогда не было CamelCase.

— Марк Рендл
источник
2
Ada: Pascal_Case_With_Underscores
— uetoyo,
6
Это не имеет смысла, если вы хотите получить доступ к одной и той же таблице на двух разных языках, которые имеют разные соглашения об именах.
— Дэниел В.
5

Прочитав множество других мнений, я думаю, что очень важно использовать соглашения об именах в языке, согласованность более важна, чем соглашения об именах, только если вы (и будете) единственный разработчик приложения. Если вам нужна удобочитаемость (что имеет огромное значение), вам лучше использовать соглашения об именах для каждого языка. Например, в MySQL я не предлагаю использовать CamelCase, поскольку не все платформы чувствительны к регистру. Так что здесь лучше использовать подчеркивание.

— Влад Мануэль Муредан
источник
1
Абсолютно согласен!!! Особенно с MySql, когда вы запускаете его в Windows, все становится от camelCaseдо camelcase. Так что иметь змеиный футляр намного лучше. Также у Modern software however supports any kind of naming schemeвас нет никаких гарантий, что вы напишете код для последней версии софта. Особенно для базы данных - обновление версии нетривиально, когда вы думаете о затратах на регрессию.
— Cherry
2

Это мои пять центов. Я пришел к выводу, что если для одного проекта используются БД разных производителей, то есть два лучших пути:

  1. Используйте подчеркивания.
  2. Используйте кавычки в кавычках.

Причина в том, что некоторые базы данных преобразуют все символы в верхний регистр, а некоторые в нижний. Итак, если myTableон у вас станет MYTABLEили mytableкогда вы будете работать с БД.

— Павел_К
источник
1

К сожалению, на этот вопрос нет "лучшего" ответа. Как заявил @David, согласованность намного важнее, чем соглашение об именах.

— Кейн
источник
1

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

— Хавьер
источник
1

Соглашения об именах существуют в рамках языка, и разные языки имеют разные соглашения об именах.

По умолчанию в SQL регистр не учитывается; Итак, snake_case - широко используемое соглашение. SQL также поддерживает идентификаторы с разделителями; Итак, смешанный регистр в опции, например camelCase (Java, где поля == столбцы) или PascalCase (C #, где таблицы == классы и столбцы == поля). Если ваш механизм БД не может поддерживать стандарт SQL, это проблема. Вы можете решить жить с этим или выбрать другой двигатель. (И то, почему C # просто должен был отличаться, вызывает раздражение у тех из нас, кто кодирует и то, и другое.)

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

— Крис Голледж
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.