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

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

  • Имя таблицы соответствует имени и ключевому ключу основного ключа
  • Схемы по функциональной области
  • Избегайте составных первичных ключей, где это возможно (используйте уникальные ограничения)
  • Имена и названия полей списка верблюдов
  • Не префиксные таблицы с tbl_ или procs с SP_ (без венгерской нотации)
  • Базы данных OLTP должны быть по крайней мере в BCNF/4NF

ОТВЕТЫ

Ответ 1

Ввод всех вместе в один список.

Стандарты именования

  • Схемы называются функциональной областью (Продукты, Заказы, Доставка)
  • No Hungarian Notation: Нет имен типов в именах объектов (без strFirstName)
  • Не используйте зарегистрированные имена для имен объектов
  • Нет пробелов или каких-либо специальных символов в именах объектов (Alphanumber + Underscore - единственное, что разрешено)
  • Назовите объекты естественным образом (FirstName вместо NameFirst)
  • Имя таблицы должно совпадать с полем "Имя первичного ключа" и "Описание" (SalesType - SalesTypeId, SalesTypeDescription)
  • Не префикс с tbl_ или sp_
  • Код имени по имени объекта (CustomerSearch, CustomerGetBalance)
  • Имена объектов базы данных CamelCase
  • Имена столбцов должны быть уникальными.
  • Названия таблиц могут быть множественными.
  • Дайте имена предприятий всем ограничениям (MustEnterFirstName)

Типы данных

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

В коде

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

Documentation

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

Нормализация и ссылочная целостность

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

Обслуживание: запуск периодических скриптов для поиска

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

Будьте добрыми

  • Быть последовательным
  • Исправить ошибки сейчас
  • Прочитать стиль программирования SQL Joe Celko (ISBN 978-0120887972)

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

  • Ключевые слова всегда находятся в UPPERCASE;
  • Имена объектов базы данных всегда в нижнем регистре;
  • Подчеркивания заменят пробелы (т.е. не будет никаких соглашений о случае верблюда, которые распространены, скажем, на SQL Server);
  • Первичные ключи почти всегда будут называться 'id';
  • Будет применена ссылочная целостность;
  • Целочисленные значения (включая идентификаторы таблицы) обычно всегда будут NUMBER (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'

Если предложение SELECT достаточно длинное, я разделим его на одно поле в строке.

Ответ 5

  • Назовите все ограничения

Ответ 6

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

Ответ 7

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

  • Используйте имена описательных полей, которые соответствуют нормальным языковым соглашениям. Например, "FirstName" вместо "NameFirst"

  • Каждое слово в имени поля имеет заглавные буквы

  • Нет подчеркиваний

  • Не используйте обычные ключевые слова, такие как "Индекс"

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

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

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

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

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

  • Если одна таблица вызывает поле "EmployeeId", тогда EVERY SINGLE TABLE, который ссылается на него, должен использовать это имя. Его не нужно называть CustomerServiceRepId только потому, что он находится в таблице расширений.

  • Почти во всех таблицах заканчивается "s". Например: Клиенты, Заказы и т.д. После того, как в таблице содержится много записей...

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

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

  • Ищите пустые схемы

  • Ищите таблицы без первичных ключей

  • Ищите таблицы без индексов

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

    /li >

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

  • Ищите не детерминированные UDF

  • Ищите комментарии TODO, чтобы убедиться, что код в БД не имеет некоей непроверенной или предварительной версии кода.

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

Ответ 12

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

Ответ 13

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

Ответ 14

Немного нравится и не нравится.

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

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

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

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

Ответ 15

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

Ответ 16

В дополнение к нормализации к 3NF или BCNF (подробнее об этом в этот вопрос), я нашел следующее полезным:

  • Таблицы имен как существительные множественного числа
  • Названия столбцов как сигулярные

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

  • Нет ничего плохого в составных ключах, если правила 3NF или BCNF все еще сохраняются. Во многих случаях (например, в случае "многих ко многим" ) это совершенно желательно.
  • Избегайте повторения имени таблицы в именах столбцов. peoplePersonID лучше писать как table.column в любом случае и гораздо более читабельным и, следовательно, самодокументированным. People.PersonID лучше, по крайней мере для меня.
  • ON DELETE CASCADE следует использовать очень осторожно.
  • Помните, что NULL означает одно из двух: либо он неизвестен, либо не применим.
  • Помните также, что NULL имеют интересные последствия для объединений, поэтому практикуйте свои LEFT, RIGHT и FULL внешние соединения.

Ответ 17

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

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

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

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

Ответ 18

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

Ответ 19

Табличный формат 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;

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

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

Ответ 20

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

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

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

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

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

Регулярно проверяйте его.

Ответ 21

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

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

Для меня всегда полезно называть таблицы и поля их точным контентом и (для нас) на ясном испанском языке и использовать случай верхнего верблюда без пробелов:

Имя пользователя: NombreUsuario

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

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

и т.д.

Ответ 22

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

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

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

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

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

Ответ 23

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

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

Ответ 24

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

Ответ 26

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

Я только недавно, после нескольких лет согласования с этим, перешел корабль, и теперь у меня есть столбец "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 таблиц в запросе может помочь совсем немного.

Ответ 27

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

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

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

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

Ответ 28

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

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

Ответ 29

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

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

Ответ 30

Мне нравится наше соглашение об именах таблиц:

People Table
PEO_PersonID
PEO_FirstName 
...

Это помогает сделать более крупные запросы более читабельными. и соединения делают немного больше смысла:

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

Я предполагаю скорее, чем соглашение об именах, это согласованность именования.