Лучший способ назвать таблицы

Ответ 1

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

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

Я также добавлю Роба Бёка, что самое важное - это последовательность. И пока мы обсуждаем эту тему, могу ли я сделать тангенциальный комментарий о том, что вы согласуетесь с именами полей? Теперь я работаю с системой, где обнаружил, что поле "prodid" в одной таблице на самом деле представляет собой то же самое содержимое, что и "стиль" в другой, а другая система, которая "доставила" в одной таблице и "датировала" в другой.

Ответ 2

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

Кроме того, следующий параметр конфигурации, вероятно, относится к тому, что вы спрашиваете:

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)

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Удачи.

Ответ 7

Мое предпочтение заключается в использовании описательных имен и использовании оболочки Pascal (TableName).

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

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