Другие объекты базы данных

Разумное наименование других объектов базы данных, таких как первичные, уникальные и внешние ключи, помогает прежде всего в отладке программ и импорте внешних данных, когда имя нарушенного ключа выводится в сообщении об ошибке. Текст ошибки станет понятен программисту, даже если ему продиктуют его по телефону. Кроме того, в перехвате ошибок можно отловить известные строки, и снабдить их понятными комментариями. Поэтому:

Первичные ключи называем так: PK_имя_таблицы.

Уникальные: UN_имя_таблицы_имена_всех_полей (если хватит терпения и допустимой длины), или просто UN_имя_тфблицы_номер_ключа_по_порядку.

Внешние ключи: FK_имя_таблицы_имя_поля_ссылки_имя_таблицы-справочника

Заключение

Указанные правила выглядят более естественно при выполнении некоторых дополнительных условий, которые выходят за рамки проблемы наименования, но о которых стоит упомянуть. Как вы уже заметили, в рассмотренных примерах в каждой таблице есть первичный ключ, причем ключ суррогатный. В этом вопросе я являюсь поклонником мнения Анатолия Тенцера, высказанного в статье "Естественные ключи против искусственных ключей". Лучше всего, когда в первичном ключе всего одно поле. Разумные дополнения к этому правилу - это территориально распределенные базы данных, где в первичном ключе участвует еще одно поле - идентификатор узла БД, уже упоминавшиеся таблицы "много-ко-многим" (nn_), и различные реализации времязависимых таблиц с указанием сроков действия каждой записи - эти реквизиты тоже участвуют в PK.

Еще один вопрос, который напрашивается после "упорядочения" названий в БД - как автоматизировать использование этого богатства? У нас есть названия сущностей, в том числе с русской расшифровкой, названия и русская расшифровка названий полей - нельзя ли сохранить эту информацию в БД и использовать ее непосредственно в программе, ее диалогах, фильтрах, отчетах, независимо используемых компонентов и языков? К сожалению, не существует общепринятого способа сохранения таких метаданных для использования различными средами разработки. Все движения в этом направлении намертво завязаны на конкретные продукты (Репозиторий в Delphi, системный словарь в PowerBuilder, конфигуратор в 1C, метаданные в Visual FoxPro), и все они обладают определенными ограничениями и неудобствами. Так что здесь есть о чем помечтать.

Содержание Назад