Каковы некоторые из ваших наиболее полезных стандартов базы данных?

Question

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

1. Имени таблицы соответствует первичному ключу имени и описание ключа
2. Schemas по своему функциональной области
3. Избегайте составные первичные ключи, где это возможно (использовать уникальные ограничения)
4. Camel Case имен таблиц и имена полого
5. не префиксы таблиц с tbl_ или проки с sp_ (без Венгерской нотации)
6. базы данных OLTP должны быть по крайней мере в НФБК/4НФ

Answer 1

Ввод каждого вклада вместе в один список.

Naming Standards

• Schemas названы по функциональным областям (товары, заказы, в упаковке)
  
• Нет Венгерская нотация: Нет Тип имена в именах объектов (без strFirstName)
  
• Не используйте зарегистрированные ключевые слова для имен объектов.
  
• В названиях объектов нет пробелов или специальных символов (Alphanum бер + Подчеркивание только вещи разрешено)
  
• объекты Названия естественным образом (ПгвЬЫат вместо NameFirst)
  
• Имени таблицы должны соответствовать первичному ключу Имени и Описание поле (SalesType - SalesTypeId, SalesTypeDescription)
  
• не префикс tbl_ или sp_
  
• Имя код по имени объекта (CustomerSearch, CustomerGetBalance)
  
• имена объектов базы данных CamelCase
  
• имена столбцов должны быть особыми
  
• имена таблиц могут быть во множественном числе
  
• Дайте бизнес имена всех ограничений (MustEnterFirstName)
  

типы данных

• Используйте тот же тип переменной через таблицы (индекс - числовой в одной таблице и varchar в другой - не очень хорошая идея)
  
• Используйте nNVarChar для информации о клиенте (имя, адрес (ы)) и т. Д.Вы никогда не знаете, когда вы можете пойти многонациональной
  

В коде

• Ключевых слов всегда в верхнем регистре
  
• Никогда не используйте подразумеваемый присоединяется (Comma синтаксис) - всегда использовать явный внутреннее соединение/OUTER JOIN
  
• 1 ГОТОВАЯ ЛИНИЯ на линию
  
• Одна ИНЕКЕ в каждой строке не
  
• нет петель - заменить логику на основе набора
  
• Используйте короткие формы имен таблиц псевдонимов, а не A, B, C
  
• Избегайте триггеров, если нет регресса
  
• Избегайте курсоры, как чумы (читай http://www.sqlservercentral.com/articles/T-SQL/66097/)
  

Документация

• Создание диаграмм баз данных
  
• Создание словаря данных
  

Нормирование и ссылочной целостности

• Используйте только один столбец первичных ключей как можно больше. При необходимости используйте уникальные ограничения.
  
• ссылочной целостности будет всегда соблюдается
  
• Избегайте ON DELETE CASCADE
  
• OLTP должен быть по крайней мере 4НФ
  
• оценить все отношения один-ко-многим, как потенциал многих ко многим
  
• Non пользовательских моделей на основе первичных ключей
  
• Сложения Вставки вместо обновления на основе
  
• PK для FK должно быть таким же именем (Employee.EmployeeId одно и то же поле, как EmployeeSalary.EmployeeId)
  
• исключением случаев, когда есть двойной присоединиться (Person.PersonId присоединяется к PersonRelation.PersonId_Parent и PersonRelation.PersonId_Child)
  

Обслуживание: запустить периодические скрипты, чтобы найти

• схемы без таблицы
  
• Потерянные записи
  
• Таблицы без первичных ключей
  
• Таблицы без индексов
  
• Недетерминированные UDF
  
• резервное копирование, резервное копирование, резервное копирование
  

Хорош

• быть последовательным
  
• исправить ошибки Теперь
  
• SQL Программирование Стиль прочитанного Джо Селка в (ISBN 978-0120887972)
  

Answer 2

Хорошая база данных дизайн и нормализация.

Answer 3

Каждый записывает SQL-запросы (представления, хранимые процедуры и т. Д.) В том же базовом формате. Это действительно помогает развитию/поддержанию усилий в будущем.

Answer 4

Я всегда стараюсь не использовать тип в имени поля - «sFirstName», «sLastName» или «iEmployeeID». Сначала они совпадают, если что-то изменится, они будут не синхронизированы, и это будет огромная головная боль, чтобы впоследствии изменить эти имена, так как вы также должны изменить зависимые объекты.

Инструменты Intellisense и GUI делают тривиальным, чтобы выяснить, какой тип столбца, поэтому я не чувствую, что это необходимо.

Answer 5

• Назовите аналогичные целевые сохраненные procs с тем же префиксом, например, если у вас есть 3 хранимых процедуры для Person. Таким образом, все для человека сгруппировано в одном месте, и вы можете легко найти их, не просматривая все свои процессы, чтобы найти их.
  • PersonUpdate
  • PersonDelete
  • PersonCreate
• делать подобные вещи для таблиц, когда у вас есть группы таблиц с соответствующими данными. Например:
  • InvoiceHeaders
  • InvoiceLines
  • InvoiceLineDetails
• Если у вас есть возможность схем внутри базы данных, использовать их. Это гораздо приятнее видеть:
  • Invoice.Header
  • Invoice.Line.Items
  • Invoice.Line.Item.Details
  • Person.Update
  • Person.Delete
  • Person.Создать
• Не используйте триггеры, если нет другого разумного подхода для достижения этой цели.
• Дайте именам полей значащий префикс, чтобы вы могли узнать, из какой таблицы они пришли, без кого-то, кто должен объяснить. Таким образом, когда вы видите имя поля, на которое вы ссылаетесь, вы можете легко определить, из какой таблицы он.
• Используйте согласованные типы данных для полей, содержащих похожие данные, то есть не храните номер телефона в виде числа в одной таблице и varchar в другом. На самом деле, не храните его как числовое, если я натолкнулся на отрицательный номер телефона, я буду сумасшедшим.
• Не используйте пробелы или другие неясные символы в именах таблиц и полей. Они должны быть полностью буквенно-цифровыми - или если у меня были мои барабанщики, полностью алфавитные, за исключением подчеркивания. В настоящее время я работаю над унаследованной системой, где имена таблиц и полей содержат пробелы, вопросительные знаки и восклицательные знаки. Заставляет меня хотеть убить дизайнера на ежедневной основе!
• Не используйте ключевые слова синтаксиса в качестве имен объектов, это вызовет головные боли, пытающиеся извлечь данные из них. Мне не терпится обернуть имена объектов как [index], это два ненужных символа, которые мне не нужно вводить, черт возьми!

Answer 6

В дополнении к нормализации к 3NF или НФКАМ (подробнее об этом в this question), я нашел следующее полезным:

• таблицы Имени как падежи
• Имени столбцов sigular

Итак, стол «Люди» имеет столбец «Личный идентификатор».

• Нет ничего плохого в составных ключах, если правила 3NF или BCNF по-прежнему сохраняются. Во многих случаях (например, в случае «многих ко многим») это совершенно желательно.
• Избегайте повторения имени таблицы в именах столбцов. peoplePersonID лучше писать как table.column в любом случае и гораздо более читабельным и, следовательно, самодокументированным. People.PersonID лучше, по крайней мере для меня.
• ON DELETE CASCADE следует использовать очень внимательно.
• Помните, что NULL означает одно из двух: либо оно неизвестно, либо оно неприменимо.
• Помните также, что NULL имеют интересные последствия для объединений, поэтому практикуйте свои ВЛЕВО, ВПРАВО и ПОЛНЫЕ внешние соединения.

Answer 7

Я согласен с тем, что вы там поставили, кроме # 5. Я часто использую префиксы для таблиц и хранимых процедур, потому что у разрабатываемых нами систем есть много разных функциональных областей, поэтому я буду стремиться префикс таблиц и sprocs с идентификатором, который позволит им хорошо сгруппировать в Management Studio на основе какой области они принадлежат.

Пример: cjso_Users, cjso_Roles, а затем у вас есть routing_Users, routing_Roles. Это может звучать как репликация данных, но на самом деле две разные таблицы пользователей/ролей предназначены для полностью отдельных функций системы (cjso будет для клиентского приложения электронной коммерции, в то время как маршрутизация будет стоять за сотрудников и дистрибьюторов, которые используют маршрутизацию система).

Answer 8

Мои стандарты для Oracle являются:

• Ключевые слова всегда в верхнем регистре;
• Имена объектов базы данных всегда в нижнем регистре;
• Подчеркивание заменяет пробелы (т. Е. Не будет никаких соглашений о случае верблюда, которые распространены, скажем, на SQL Server);
• Первичные ключи почти всегда будут называться 'id';
• Будет обеспечена соблюдение ссылочной целостности;
• Целочисленные значения (включая идентификаторы таблицы) обычно будут НОМЕР (19,0). Причина этого в том, что это будет соответствовать 64-битовому значению целого числа, что позволит использовать длинный тип Java вместо более неудобного BigInteger;
• Несмотря на неправильное имя добавления «_number» к некоторым именам столбцов, тип таких столбцов будет VARCHAR2, а не типом числа. Типы номеров зарезервированы для первичных ключей и столбцов, на которые выполняется арифметика;
• Я всегда использую технические первичные ключи; и
• Каждая таблица будет иметь собственную последовательность для генерации ключей. Название этой последовательности будет _seq.

С SQL Server единственная модификация - использовать случай верблюда для имен объектов базы данных (например, имя_пользователя вместо имени_папки).

Запросы будут иметь тенденцию быть написаны Многострочный с одной оговоркой или состояния в каждой строке:

SELECT field1, field2, field2 
FROM tablename t1 
JOIN tablename2 t2 ON t1.id = t2.tablename_id 
WHERE t1.field1 = 'blah' 
AND t2.field2 = 'foo' 

Если ВЫБРАТЬ условие достаточно долго, я разделить его одно поле в каждой строке.

Answer 9

Согласованные стандарты именования. Наличие всех на одной странице, используя тот же формат (будь то Camel Case, конкретные префиксы и т. Д.), Помогает поддерживать точность системы.

Answer 10

Мне нравится наш стол именования:

People Table 
PEO_PersonID 
PEO_FirstName 
... 

, который помогает сделать больше querys немного более удобным для чтения. и присоединяется сделать немного больше смысла:

Select * -- naughty! 
From People 
Join Orders on PEO_PersonID = ORD_PersonID 
--... 

я догадываюсь, а не то, что соглашение об именах, являюсь консистенцией наименования.

Answer 11

не забудьте регулярно создавать резервные копии баз данных.

Answer 12

1. Не используйте имена типов в именах полей. Старшие ребята запомнят старый стандарт MS lpszFieldName и ту глупость, которая последовала.

2. Используйте описательные имена полей, которые соответствуют нормальным языковым соглашениям.Например «ПгвЬЫате» вместо «NameFirst»

3. Каждое слово в названии поля капитализируются

4. Нет подчеркивает

5. Не используйте обычные ключевые слова, такие как «Index»

6. Не префикс НИЧЕГО с типом объекта. Например, мы НЕ используем tblCustomers или spCustomersGet. Они не допускают хорошей сортировки и обеспечивают нулевое значение.

7. Используйте схемы для определения отдельных областей базы данных. Такие как sales.Customers и hr.Employees. Это избавит вас от большинства префиксов, которые люди используют.

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

9. Используйте виды для сложных объединений.

10. Избегайте сложных соединений, если это возможно. Может быть более приятным было бы иметь таблицу CustomerPhoneNumbers; но, честно говоря, сколько телефонных номеров нам нужно хранить? Просто добавьте поля в таблицу Customers. Ваши запросы БД будут быстрее, и это намного легче понять.

11. Если одна таблица вызывает поле «EmployeeId», тогда КАЖДЫЙ SINGLE TABLE, который ссылается на него, должен использовать это имя. Его не нужно называть CustomerServiceRepId только потому, что он находится в таблице расширений.

12. Почти все таблицы имеют «s» окончание. Например: Клиенты, Заказы и т. Д. После того, как в таблице содержится много записей ...

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

14. Связывание таблиц, поддерживающих многие и многие отношения, имеет обе связанные таблицы в имени. Например, SchoolsGrades. Очень легко сказать по имени таблицы, что он делает.

15. Будьте СОГЛАСНЫ. Если вы начинаете с одного из своих конвенций, не меняйте лошадей на полпути, если только вы не захотите реорганизовать всю предыдущую работу. Это должно поставить тормоза на любые идеи «не было бы здорово, если ...», которые в конечном итоге вызывают путаницу и огромное количество переделок.

16. Подумайте, прежде чем набрать. Вам действительно нужна эта таблица, поле, sproc или view? Вы уверены, что это не покрыто где-то еще? Получите консенсус перед его добавлением. И если по какой-то причине вы должны его вытащить, сначала поговорите с вашей командой. Я был в местах, где администраторы баз данных ежедневно меняют свои изменения, не обращая внимания на разработчиков. Это не весело.

Answer 13

Документировать все; Документация типа wiki проста в настройке, и программное обеспечение является бесплатным.

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

Затем определите стандарт и версию базы данных, к которой вы собираетесь работать.Определить стандарты для элементов кода (представления, функции и т. Д.), Именования базы данных; соглашения об именах для столбцов, таблиц; соглашения типов для столбцов; шаблоны кодирования.

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

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

Просмотрите его регулярно.

Answer 14

Предложение WITH действительно помогает разбить запросы на управляемые части.

Это также действительно помогает повысить эффективность планов выполнения запросов.

Answer 15

• Имя все ограничения

Answer 16

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

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

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

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

Answer 17

Одна вещь, которую я не видел упоминается еще:

Никогда не используйте ключевые слова базы данных в качестве имен объектов. Вы не хотите, чтобы их подбирали каждый раз, когда вы их используете.

Если вы что-то не заметили, создав его, исправьте его, как только заметите это. Не тратьте годы, чтобы помнить, что в этой таблице UserName действительно Usernmae. Это намного легче исправить, если на него не написано много кода.

Никогда не используйте подразумеваемые соединения (синтаксис запятой), всегда указывайте соединения.

Answer 18

13- Оценивать ваши запросы

То верно. Иногда вы не получаете то, что хотели.

Для меня, это всегда полезно назвать таблицы и поля с их точным содержанием и (для нас) в ясном испанском и с использованием верхнего ГорбатыйРегистр, без пробелов: Имя

Пользователь: NombreUsuario

Первая Фамилия: ApellidoPaterno

Второй Фамилия: ApellidoMaterno

и т.д. и т.п.

Answer 19

• Таблицы названы в единственном числе, в нижнем регистре, не подчеркивания, без префикса
• Fields также в нижнем регистре, не подчеркивания, без префикса
• Хранимые процедуры с приставкой «st_» (сортов Красиво)
• Views, которые относятся как таблицы не имеют никакого префикса
• просмотров созданных для специальных отчетов и т.д. имеют «V» префикс
• индексированных представления, созданные для исполнения имеет префикс «ixv»
• всех индексы имеют целенаправленные имена (нет автоматического присвоения имен)
• Сильно предпочитайте uniqueidentifier (с последовательным приращением) по int IDENTITY для суррогатных ключей
• Не искусственно ограничивайте поля VARCHAR/NVARCHAR до 100 или 255. Дайте им место для дыхания. Это не 1980-е годы, поля не сохраняются с максимальной длиной.
• 3NF минимальный стандарт
• Предпочитает соединение таблиц с внешними ключами на уровне столбца: многие предположения 1: m оспариваются по мере того, как система растет с течением времени.
• Всегда используйте суррогатные ключи, а не натуральные ключи, в качестве первичного ключа. Все предположения о «естественных» ключах (SSN, имена пользователей, номера телефонов, внутренние коды и т. Д.) В конечном итоге будут оспорены.

Answer 20

Убедитесь, что каждый выбор varchar/nvarchar является подходящим.

Убедитесь, что каждый выбор столбца NULLable является подходящим - избегайте столбцов NULLable, где это возможно, что позволяет NULL быть оправданным положением.

Независимо от любых других правил, которые вы можете использовать из предложений здесь, я бы создал хранимую процедуру в базе данных, которая может запускаться на регулярной основе для определения состояния системы для любых правил или стандартов, которые у вас есть (некоторые из этих немного SQL-Server конкретный):

• Ищет потерянные записи в любых случаях, когда ссылочная целостность системы СУБД не может быть использована по какой-то причине (в моей системе у меня есть таблица процессов и таблица испытаний - поэтому мой system_health SP ищет процессы без тестов, так как у меня только односторонняя связь FK)

• Посмотрите на пустые схемы

• просмотровых таблиц без первичных ключей

• Посмотрите для таблиц без индексов

• Посмотрите на объекты базы данных без документации (мы используем свойства SQL Server Extended поставить документацию в базе данных - эта документация может быть такой же гранулированной, как колонка ).

• Ищите проблемы, связанные с системой, - таблицы, которые необходимо заархивировать, исключения, которые не являются частью обычной ежемесячной или ежедневной обработки, некоторые общие имена столбцов с настройками или без них (CreateDate, скажем).

• Посмотрите на недетерминированных UDF,

• Посмотрите на TODO комментарии, чтобы гарантировать, что код в БД не как-то есть код непроверенных или пре-релиз.

Все это может быть автоматизировано, чтобы дать вам общую картину состояния системы.

Answer 21

Табличный формат SQL.

select a.field1, b.field2 
from  any_table a 
inner join blah  b on b.a_id  = a.a_id 
inner join yet_another y on y.longer_key = b.b_id 
where a.field_3   > 7 
and b.long_field_name < 2; 

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

С таким видом форматирования я могу быстрее ответить на общие вопросы типа «какая таблица сглажена« а »?» и «какие поля присоединяют таблицу T к запросу?» Структура не займет много времени, чтобы применить или обновить, и я считаю, что это экономит много времени. Мы тратим больше времени на чтение кода, чем написание его.

Answer 22

Несколько нравится и не любит.

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

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

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

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

Answer 23

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

Answer 24

Принимая «базу данных» для обозначения «продукта SQL», мой ответ: «Слишком много, чтобы упомянуть. Вы могли бы написать целую книгу по этому вопросу». К счастью, у кого-то есть.

Мы используем стиль программирования SQL Joe Celko (ISBN 978-0120887972): «Эта книга представляет собой набор эвристик и правил, советов и трюков, которые помогут вам улучшить стиль и знания SQL-программирования, а также для форматирования и записи переносных , читаемый, поддерживаемый код SQL ».

Преимущества этого подхода заключается в том, включают:

• парень знает больше о такого рода вещах, чем у меня (есть еще одна книга на эвристических SQL ?!);
• Работа выполнена. Я могу дать книгу кому-то в команде, чтобы прочитать и обратиться к ней;
• Если кому-то не нравится мой стиль кодирования, я могу обвинить кого-то другого;
• Недавно я получил нагрузку повторения на SO, рекомендуя другую книгу Celko :)

На практике мы отклониться от предписаний книги, но на удивлении редко.

Answer 25

В MS-SQL у меня всегда были объекты, принадлежащие dbo., И я префиксные вызовы для этих объектов с dbo.

Слишком много раз я видел, как наши разработчики удивлялись, почему они не могут назвать свои объекты, которые они принадлежали.

Answer 26

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

Answer 27

MVP Aaron Bertrand's "My stored procedure "best practices" checklist"

Answer 28

Имя таблицы соответствует первичного ключа имя и описание ключа

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

Да, я знаю, при соединении столов это сложно! Но так связывает ProductID с ProductID, так что, ну, почему дополнительный ввод?

Это:

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ID 

немного лучше, чем это:

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ProductID 

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

Answer 29

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

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

Первичный ключ в таблице имеет то же имя, что и таблица, с суффиксом _PK. Внешние ключи имеют то же имя, что и соответствующий первичный ключ, но с суффиксом _FK. Например, первичный ключ таблицы продуктов называется Product_PK; в таблице заказов соответствующий внешний ключ - Product_FK. Я выбрал эту привычку у другого друга из DBA, и до сих пор мне это нравится.

Всякий раз, когда я выполняю INSERT INTO ... SELECT, я, как и все столбцы в секции SELECT, сопоставляю имена столбцов с частью INSERT INTO, чтобы упростить ее поддержку и посмотреть, как все будет соответствовать.

Answer 30

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

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