Всякий раз, когда я создаю базу данных, я всегда задаюсь вопросом, есть ли лучший способ именования элемента в моей базе данных. Я часто задаю себе следующие вопросы:
Существуют ли какие-либо рекомендуемые рекомендации для присвоения имен в базе данных?
Я рекомендую проверить образцы баз данных Microsoft SQL Server: http://codeplex.com/SqlServerSamples
В примере AdventureWorks используется очень четкое и согласованное соглашение об именах, которое использует имена схем для организации объектов базы данных.
Поздний ответ здесь, но вкратце:
Разработка:
(1) Что вы должны делать. Есть очень мало вещей, которые вы должны делать определенным образом, каждый раз, но есть несколько.
(2) Что вы, вероятно, должны делать.
(3) Что вы должны учитывать.
Хорошо, поскольку мы взвешиваем мнение:
Я считаю, что имена таблиц должны быть множественными. Таблицы представляют собой коллекцию (таблицу) объектов. Каждая строка представляет собой единый объект, а таблица представляет коллекцию. Поэтому я бы назвал таблицу лиц-лиц Людей (или лиц, что бы ни привлекало ваше воображение).
Для тех, кто любит видеть уникальные имена сущностей в запросах, это то, что я хотел бы использовать псевдонимы таблиц для:
SELECT person.Name
FROM People person
Немного похоже на LINQ "от человека в людях выберите person.Name".
Что касается 2, 3 и 4, я согласен с @Lars.
Я работаю в команде поддержки базы данных с тремя администраторами баз данных, и наши рассмотренные варианты:
Мы используем уникальные имена для таблиц. Таблицы имеют префикс с именем системы (или ее сокращением). Это полезно, если системный комплекс, так как вы можете изменить префикс для логической группировки таблиц (например, reg_customer, reg_booking и regadmin_limits).
Для полей мы ожидаем, что имена полей будут включать префикс /acryonm таблицы (т.е. cust_address1), и мы также предпочитаем использовать стандартный набор суффиксов (_id для PK, _cd для "code", _nm для "name", _nb для "number", _dt для "Date" ).
Название поля ключа Foriegn должно совпадать с полем основного поля.
то есть.
SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id
При разработке нового проекта я бы рекомендовал вам выписать все предпочтительные имена сущностей, префиксы и акронимы и предоставить этот документ вашим разработчикам. Затем, когда они решат создать новую таблицу, они могут ссылаться на документ, а не "угадывать", что следует вызывать таблицу и поля.
Ok. Thats мои $0.02
Я также выступаю за соглашение об именах стилей ISO/IEC 11179, отмечая, что они являются рекомендациями, а не предписывающими.
См. Имя элемента данных в Википедии:
"Таблицы являются сборниками сущностей и следуют правилам именования коллекций. В идеале используется коллективное имя: например, Персонал. Плюрализм также правильный: сотрудники. Неправильные имена включают в себя: Employee, tblEmployee и EmployeeTable."
Как всегда, существуют исключения из правил, например. таблица, которая всегда имеет ровно одну строку, может быть лучше с единственным именем, например. таблицу конфигурации. И согласованность имеет первостепенное значение: проверьте, есть ли у вас магазин соглашение и, если да, следуйте ему; если вам это не нравится, тогда сделайте бизнес-кейс, чтобы он изменился, а не одиноким рейнджером.
наше предпочтение:
Должны ли имена таблиц быть множественными?
Никогда. Аргументы для него - это коллекция, но вы никогда не знаете, что таблица будет содержать (0,1 или много элементов). Множественные правила делают именование излишне сложным. 1 дом, 2 дома, мышь против мышей, человек против людей, и мы даже не смотрели на какие-либо другие языки.
Update person set property = 'value' действует на каждого человека в таблице. Select * from person where person.name = 'Greg' возвращает набор строк/строк строк.
Должны ли имена столбцов быть единственными?
Обычно да, кроме случаев, когда вы нарушаете правила нормализации.
Должен ли я префикс таблиц или столбцов?
В основном предпочтение от платформы. Мы предпочитаем префикс столбцов с именем таблицы. Мы не префиксные таблицы, но мы делаем префиксные представления (v_) и stored_procedures (sp_ или f_ (function)). Это помогает людям, которые хотят попробовать обновить v_person.age, который на самом деле является вычисленным полем в представлении (которое не может быть UPDATEd в любом случае).
Это также отличный способ избежать столкновения с ключевыми словами (доставка. из перерывов, но с доставкой не получается).
Это делает код более подробным, но часто помогает в удобочитаемости.
bob = new person() bob.person_name = 'Bob' bob.person_dob = '1958-12-21'
... очень читабельна и ясна. Это может выйти из-под контроля:
customer.customer_customer_type_id
указывает связь между клиентом и таблицей customer_type, указывает первичный ключ в таблице customer_type (customer_type_id), и если вы когда-либо видели "customer_customer_type_id" при отладке запроса, вы сразу же знаете, где он находится (таблица клиентов).
или где у вас есть отношения M-M между customer_type и customer_category (для определенных категорий доступны только определенные типы)
customer_category_customer_type_id
... немного (!) на длинной стороне.
Должен ли я использовать какой-либо случай в именовании элементов? Да - нижний регистр:), с подчеркиванием. Это очень читаемая и кросс-платформа. Вместе с 3 выше это также имеет смысл.
Однако большинство из них - предпочтения. - Пока вы последовательны, это должно быть предсказуемо для всех, кто должен его прочитать.
Взгляните на ISO 11179-5: Принципы именования и идентификации Вы можете получить его здесь: http://metadata-standards.org/11179/#11179-5
Я писал об этом некоторое время назад: ISO-11179 Соглашения об именах
Мое мнение о них:
1) Нет, имена таблиц должны быть единственными.
В то время как кажется, что имеет смысл для простого выбора (select * from Orders), он имеет меньшее значение для эквивалента OO (Orders x = new Orders).
Таблица в БД - это действительно набор этого сущностей, это имеет больше смысла, когда вы используете set-logic:
select Orders.*
from Orders inner join Products
on Orders.Key = Products.Key
Эта последняя строка, фактическая логика соединения, выглядит запутанной с именами множественных таблиц.
Я не уверен в том, что всегда использую псевдоним (как утверждает Мэтт).
2) Они должны быть сингулярными, поскольку они содержат только 1 свойство
3) Никогда, если имя столбца неоднозначно (как указано выше, где оба они имеют столбец с именем [Key]), имя таблицы (или ее псевдоним) может отличать их достаточно хорошо. Вы хотите, чтобы запросы были быстрыми и понятными - префиксы добавляют излишнюю сложность.
4) Что бы вы ни хотели, я бы предложил CapitalCase
Я не думаю, что есть один набор абсолютных рекомендаций по любому из них.
Пока все, что вы выбираете, согласовано между приложением или БД, я не думаю, что это действительно имеет значение.
Я знаю, что это слишком поздно для игры, и на вопрос уже был дан ответ уже очень хорошо, но я хочу высказать свое мнение о №3 относительно префикса имен столбцов.
Все столбцы должны быть названы с префиксом, который уникален для таблицы, в которой они определены.
например. Учитывая таблицы "клиент" и "адрес", отпустите с префиксами "cust" и "addr", соответственно. "клиент" имел бы "cust_id", "cust_name" и т.д. в нем. "address" будет иметь "addr_id", "addr_cust_id" (FK обратно клиенту), "addr_street" и т.д. в нем.
Когда я впервые был представлен этим стандартом, я был мертв против него; Я ненавидел эту идею. Я не мог выдержать идею о том, что это лишний набор и избыточность. Теперь у меня было достаточно опыта, чтобы я никогда не возвращался.
Результатом этого является то, что все столбцы в схеме базы данных уникальны. Для этого есть одно важное преимущество, которое превосходит все аргументы против него (на мой взгляд, конечно):
Вы можете искать всю базу кода и надежно находить каждую строку кода, которая касается конкретного столбца.
Преимущество №1 невероятно велико. Я могу обесценить столбец и точно знать, какие файлы необходимо обновить до того, как столбец можно безопасно удалить из схемы. Я могу изменить значение столбца и точно знать, какой код нужно реорганизовать. Или я просто могу сказать, используются ли данные из столбца в определенной части системы. Я не могу сосчитать количество раз, когда это превратило потенциально огромный проект в простой, а также количество часов, которые мы сохранили в процессе разработки.
Другим, относительно небольшим преимуществом для него является то, что вам нужно использовать табличные псевдонимы, когда вы делаете самостоятельное соединение:
SELECT cust_id, cust_name, addr_street, addr_city, addr_state
FROM customer
INNER JOIN address ON addr_cust_id = cust_id
WHERE cust_name LIKE 'J%';
Я все время слышу, что аргумент о том, что плюрализуется таблица, - это все личный вкус, и нет лучшей практики. Я не верю, что это правда, особенно как программист, а не DBA. Насколько мне известно, нет никаких законных оснований для плюрализации имени таблицы, отличного от "Это просто имеет смысл для меня, потому что это коллекция объектов", в то время как есть законные выигрыши в коде с помощью уникальных имен таблиц. Например:
Это позволяет избежать ошибок и ошибок, вызванных множественными двусмысленностями. Программисты точно не известны своими знаниями о правописании, а плюризация некоторых слов сбивает с толку. Например, слово множественного числа заканчивается на "es" или просто "s"? Это люди или люди? Когда вы работаете над проектом с большими командами, это может стать проблемой. Например, экземпляр, в котором член команды использует неправильный метод для размножения созданной таблицы. К тому времени, когда я взаимодействую с этой таблицей, она используется повсюду в коде, к которому у меня нет доступа или потребуется долго исправлять. В результате я должен помнить, что каждый раз, когда я его использую, неправильно повторяю таблицу. Что-то очень похожее на это произошло со мной. Чем проще вы можете сделать это для каждого члена команды, чтобы последовательно и легко использовать точные, правильные имена таблиц без ошибок или постоянно искать имена таблиц, тем лучше. Единственная версия гораздо проще обрабатывать в командной среде.
Если вы используете единственную версию имени таблицы И префикс первичного ключа с именем таблицы, теперь у вас есть преимущество в том, что вы легко можете определить имя таблицы из первичного ключа или наоборот с помощью кода. Вы можете получить переменную с именем таблицы в ней, объединить "Id" до конца, и теперь у вас есть первичный ключ таблицы через код, без необходимости делать дополнительный запрос. Или вы можете отключить "Id" с конца первичного ключа, чтобы определить имя таблицы через код. Если вы используете "id" без имени таблицы для первичного ключа, вы не можете через код определить имя таблицы из первичного ключа. Кроме того, большинство людей, которые используют множественные имена таблиц и префиксные столбцы PK с именем таблицы, используют уникальную версию имени таблицы в PK (например, статусы и statusId), что делает невозможным это вообще.
Если вы делаете имена таблиц сингулярными, вы можете сопоставить имена классов, которые они представляют. Еще раз, это может упростить код и позволить вам делать действительно аккуратные вещи, такие как создание экземпляра класса, имея только имя таблицы. Это также просто делает ваш код более последовательным, что приводит к...
Если вы делаете имя таблицы уникальным, это делает вашу схему именования последовательной, организованной и простой в обслуживании в каждом месте. Вы знаете, что в каждом экземпляре вашего кода, будь то имя столбца, имя класса или имя таблицы, оно имеет то же точное имя. Это позволяет выполнять глобальные поиски, чтобы везде видеть, что данные используются. Когда вы дублируете имя таблицы, будут случаи, когда вы будете использовать сингулярную версию имени этой таблицы (класс, в который он входит, в первичном ключе). Просто имеет смысл не иметь некоторых случаев, когда ваши данные упоминаются как множественное число, а некоторые экземпляры сингулярны.
Подводя итог, если вы дублируете свои имена таблиц, вы теряете всевозможные преимущества, чтобы сделать ваш код умнее и проще в обращении. Могут даже быть случаи, когда вы должны иметь таблицы поиска/массивы для преобразования имен таблиц в имена объектов или локальных кодов, которых вы могли бы избежать. Сингулярные имена таблиц, хотя, возможно, сначала немного странные, дают значительные преимущества перед плюрализованными именами, и я считаю, что это лучшая практика.
По-моему:
Однако, как уже упоминалось, любое соглашение лучше, чем никакое соглашение. Независимо от того, как вы это сделаете, запишите его так, чтобы будущие изменения соответствовали тем же соглашениям.
Думаю, лучший ответ на каждый из этих вопросов даст вам и вашей команде. Гораздо важнее иметь соглашение об именах, как именно соглашение об именах.
Поскольку нет правильного ответа на это, вы должны потратить некоторое время (но не слишком много) и выбрать свои собственные соглашения и - вот важная часть - придерживаться его.
Конечно, неплохо искать некоторую информацию о стандартах по этому вопросу, о чем вы просите, но не беспокойтесь и не беспокоитесь о количестве различных ответов, которые вы можете получить: выберите тот, который кажется вам лучше.
На всякий случай, вот мои ответы:
Соглашения об именах позволяют команде разработчиков разрабатывать открытость и ремонтопригодность в центре проекта.
Хорошее соглашение об именах требует времени, чтобы развиваться, но как только он на месте, он позволяет команде двигаться вперед с общим языком. Хорошее соглашение об именах органично развивается с проектом. Хорошее соглашение об именах легко справляется с изменениями в течение самой продолжительной и самой важной фазы жизненного цикла программного обеспечения - управление услугами в производстве.
Вот мои ответы:
Именование жестко, но в каждой организации есть кто-то, кто может называть вещи, и в каждой команде программного обеспечения должен быть кто-то, кто берет на себя ответственность за стандарты прошивки и гарантирует, что проблемы с именами, такие как sec_id, sec_value и security_id, будут решены раньше, чем они будут испечены в проект.
Итак, каковы основные принципы хорошего соглашения и стандартов именования: -
Здесь есть ссылка, которая предлагает несколько вариантов. Я искал простую спецификацию, которой я мог следовать, вместо того, чтобы полагаться на частично определенный.
SELECT
UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY Lastname
Названия таблиц всегда должны быть сингулярными, поскольку они представляют собой набор объектов. Как вы говорите, стадо назначать группу овец, или стадо обозначают группу птиц. Нет необходимости во множественном числе. Когда имя таблицы представляет собой состав из двух имен, а соглашение об именах во множественном числе, становится трудно узнать, должно ли имя множественного числа быть первым словом или вторым словом или и тем, и другим. Его логика - Object.instance, а не objects.instance. Или TableName.column, а не TableNames.column(s). Microsoft SQL не чувствителен к регистру, его легче читать имена таблиц, если используются буквы верхнего регистра, для разделения имен таблиц или столбцов, когда они состоят из двух или более имен.
Имя таблицы: Оно должно быть сингулярным, поскольку оно представляет собой единый объект, представляющий объект реального мира, а не объекты, который является одиночным.
Имя столбца: Оно должно быть сингулярным только тогда, когда оно передает, что оно будет содержать атомное значение и подтвердит теорию нормализации. Если, однако, существует n число одинаковых типов свойств, то они должны быть суффиксными с 1, 2,..., n и т.д.
Префикс Таблицы/Столбцы: Это огромная тема, которая будет обсуждаться позже.
Корпус: должен быть чехол Camel
Мой друг, Патрик Карчер, я прошу вас не пишите ничего, что может быть оскорбительным для кого-то, как вы писали ". Кроме того, внешние ключи должны быть последовательно названы в разных таблицах. должно быть законно избивать кого-то, кто этого не делает". Я никогда не совершал этой ошибки, мой друг Патрик, но я пишу вообще. Что, если они вместе планируют избить тебя за это?:)
Очень поздно вечеринке, но я все еще хотел добавить свои два цента о префиксах столбца
Кажется, существуют два основных аргумента в пользу использования стандарта имен table_column (или tableColumn) для столбцов, основанного на том, что само имя столбца будет уникальным для всей вашей базы данных:
1) Вам не нужно указывать имена таблиц и/или псевдонимы столбцов в ваших запросах все время
2) Вы можете легко найти весь код для имени столбца
Я думаю, что оба аргумента ошибочны. Решение обеих проблем без использования префиксов легко. Вот мое предложение:
Всегда используйте имя таблицы в своем SQL. Например, всегда используйте table.column вместо столбца.
Он, очевидно, решает 2), поскольку теперь вы можете просто искать table.column вместо table_column.
Но я слышу, как вы кричите, как он решает 1)? Это было как раз об этом. Да, это было, но решение было ужасно ошибочным. Зачем? Ну, префиксное решение сводится к:
Чтобы избежать необходимости указывать table.column при двусмысленности, вы назовете все свои столбцы table_column!
Но это означает, что вы теперь будете ВСЕГДА писать имя столбца каждый раз, когда вы укажете столбец. Но если вы все равно должны это делать, то какая польза от явного написания таблицы table.column? Точно, нет никакой пользы, это то же самое количество символов для ввода.
edit: да, я знаю, что именование столбцов с префиксом обеспечивает правильное использование, тогда как мой подход зависит от программистов
Основные обозначения именования баз данных (и стиль) (нажмите здесь для более подробного описания)
имена таблиц выбирать короткие, недвусмысленные имена, используя не более одного или двух слов легко различать таблицы упрощает назначение имен уникальных полей, а также поиск и привязку таблиц дайте таблицы сингулярным именам, никогда не множественное число (обновление: я до сих пор согласен с причинами, приведенными для этого соглашения, но большинству людей действительно нравятся множественные имена таблиц, поэтому ive смягчило мою позицию)... следуйте по ссылке выше, пожалуйста,
Названия таблиц единичные. Скажем, вы моделировали реальность между кем-то и их адресом. Например, если вы читаете datamodel, вы бы предпочли "каждый человек может проживать по 0,1 или много адресов". или "каждый человек может жить по 0,1 или много адресов". Я считаю, что его проще адресовать адрес, а не перефразировать людей как личность. Плюс коллективные существительные довольно часто расходятся с сингулярным вариантом.
--Example SQL
CREATE TABLE D001_Students
(
StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);
CREATE INDEX idxD001_STID on D001_Students;
CREATE TABLE D002_Classes
(
ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
CONSTRAINT fkD001_STID FOREIGN KEY(StudentID)
REFERENCES D001_Students(StudentID)
);
CREATE INDEX idxD002_CLID on D002_Classes;
CREATE VIEW V001_StudentClasses
(
SELECT
D001.ChristianName,
D001.Surname,
D002.ClassName
FROM
D001_Students D001
INNER JOIN
D002_Classes D002
ON
D001.StudentID = D002.StudentID
);
Это конвенции, которым меня учили, но вы должны адаптироваться к тому, что использует ваш шланг для разработки.