Вы предпочитаете подробное именование когда дело доходит до столбцов базы данных? [закрытый]

Я - поклонник опции 3:

CREATE TABLE Products
(
    ProductId int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    CategoryId int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryId),
    Name varchar(200) NOT NULL
)

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

Проверка также связала вопрос: снабжает префиксом каждое имя поля в таблице с сокращенным именем таблицы хорошая практика?

Поскольку я упомянул в своем ответе; понятие добавления префикса имен полей с именем таблицы прибывает со старого времени унаследованных систем, когда каждое поле через целую базу данных должно было быть уникальным. Это больше не требуется современными системами, таким образом, это - просто конвенция, которая больше не необходима. Как упомянуто Думают Прежде, чем Кодировать "Имя таблицы, уже дает контекст. Никакая потребность к столбцам префикса не называет с ним"

Я обычно даю каждой таблице уникальный префикс. Таким образом, Ваш пример был бы чем-то как

CREATE TABLE Products
(
    PROD_ID int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    PROD_CAT_ID int NOT NULL FOREIGN KEY REFERENCES Categories(CAT_ID),
    PROD_NAME varchar(200) NOT NULL
)

Это делает присоединение и выбор столбцов легче, потому что у Вас нет конфликтов имен. Если Вы не сошлетесь на ту же таблицу несколько раз, Вам даже не будут нужны псевдонимы имени таблицы (скорее всего).

Однако в последнее время я запускаю к вещи, которая (2) могла бы быть лучше, потому что это ближе к соглашениям о присвоении имен, которые я использую когда написание кода (C# в моем случае).

Я придерживаюсь со столь же коротким максимально имена. Люди, снабжающие префиксом название таблицы на каждом столбце, делают меня жестоким. Человек first_name, не Человек person_first_name. Мы знаем, что это - человек, в таблице человека..., чем еще это было бы?

Единственное время я иду вразрез с этим правилом, для идентификатора colums, например: PERSON.personID.

Правило с извинениями Einstein; быть столь же подробным по мере необходимости, но более подробным.

Идентификатор ужасно сбивает с толку, когда у Вас есть много соединений. Я предпочитаю иметь explict названия идентификаторов, которые соответствуют названию идентификатора во внешнем ключе. Тем путем Вы всегда знаете, что customerid присоединится к customerid в любой другой таблице, которая имеет столбец.

Никогда не используйте имя в качестве имени поля. Это - зарезервированное слово и таким образом должно избежаться. Зарезервированные keyworsds используются базой данных некоторым способом, использование их также как зарегистрированные имена является просто плохим proactice и может создать больше ошибок, чем использование корректного описательного имени формирует запуск.

Я предпочитаю uid, ценуроз, pid, wid, крышку, и т.д.

Я думаю, не ли имя столбца уникально в базе данных, необходимо снабдить префиксом его имя таблицы. Как, ProductId, ProductName. Для столбцов, не конфликтующих со столбцами в другой таблице, не снабжайте префиксом его.

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

С другой стороны, я соглашаюсь до некоторой степени с, Думают Перед логикой Кодирования. Я всегда использую table.column синтаксис, таким образом, контекст должен быть ясным.

Используя более подробные имена столбцов обычно избегает конфликтов с зарезервированными словами.

С другой стороны это может быть довольно избыточно, если каждым столбцом в Вашей таблице product является ProductXxxx.

Другими словами, у меня нет абсолютного предпочтения, но я действительно склоняюсь больше к подробному соглашению о присвоении имен.

Я предпочитаю придерживаться короткой версии "идентификатора". Это - легкое, чтобы понять и следовать конвенции, что идентификатор записи для таблицы назвали бы "идентификатором", и это будет относиться к своей "собственной" таблице а не к чему-то еще (хотя иногда нет никакой потребности в "собственном" идентификаторе в некоторых таблицах как отображения).

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

Это упрощает вещи.

Вариант 2 - лучший (для меня конечно :)),
Я программист PHP, а не .NET.

Я предпочитаю второй вариант, потому что первый вариант мне кажется ненужным повторением. Конечно, я в первую очередь программист на Ruby on Rails, поэтому мне нравится принцип DRY . :) Мне было неприятно заниматься программированием на C #, потому что все действительно используют первую, явно повторяющуюся версию.