Лучший способ назвать таблицы - PullRequest
12 голосов
/ 23 июня 2010

Лучше ли использовать подчеркивание при именовании таблиц или лучше использовать camelcase?

Пример table_name или tableName какой из них лучше? Есть ли причина использовать что-то еще?

Ответы [ 7 ]

12 голосов
/ 23 июня 2010

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

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

Я также буду вторым Робом Буэком по самой важной вещи - последовательности.И в то время как мы находимся на предмете, могу ли я сделать тангенциальный комментарий о последовательности в именах полей?Сейчас я работаю с системой, в которой я обнаружил, что поле «prodid» в одной таблице фактически совпадает с содержимым «style» в другой таблице, а другая система имеет «deliverydate» в одной таблице и «datedelivered» вдругой.

3 голосов
/ 23 июня 2010

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

mysql> show global variables like 'lower%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_file_system | OFF   |
| lower_case_table_names | 0     |
+------------------------+-------+
2 rows in set (0.00 sec)

Что касается имен полей, я склонен использовать верблюжий случай.

2 голосов
/ 23 июня 2010

Я полагаю, что многие РСУБД игнорируют регистр, поэтому использование схем именования в случае верблюда может просто не сработать.

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

1 голос
/ 23 июня 2010

Я предпочитаю использовать описательные имена и использовать регистр Pascal (TableName).

Избегайте аббревиатур, и если вам нужно использовать аббревиатуру, относитесь к ней как к слову (используйте DaylightSavingsTimeInfo или DstInfo вместо DSTInfo).

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

1 голос
/ 23 июня 2010

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

Вы должны делать все, что удобно для вас, и что лучше вытекает из вашей клавиатуры.

По своему опыту я перешел в ROR из .net некоторое время назад и был пойман тем, что всегда видел, как люди делают такие вещи, и подчеркивал мои таблицы, но через некоторое время я упустил эту опцию из-за своего старого доброго удобства именования SQL .

то же самое для столбцов.

Удачи

1 голос
/ 23 июня 2010

Вместо того, чтобы предоставить вам краткую обратную связь по нескольким причинам для этого и что я предоставлю ссылку на рекомендации по кодированию SQL Pinal Dave.Они были хорошо продуманы, объяснены и, кажется, следуют моим собственным предпочтениям о том, как вещи должны быть названы и использованы и т. Д.

Наслаждайтесь!

1 голос
/ 23 июня 2010

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

Например, если вы инкапсулируете данные * в классе с именем UserInfo, таблицадолжен также называться UserInfo.

* Вы инкапсулируете данные, верно?

...