Классика баз данных - статьи

       

внутренний идентификатор, суррогатный ключ. Автоинкрементный.



  • id - внутренний идентификатор, суррогатный ключ. Автоинкрементный. От пользователя скрывается. Никогда не модифицируется.


  • code - пользовательский идентификатор, уникальный ключ. Например, табельный номер сотрудника. Как правило, неизменный; но при необходимости его можно менять (когда у отдела кадров сносит крышу), причем без каскадных обновлений БД.


  • name - имя чего-либо (скорее идентификатор, или нечто каноническое)


  • label - название (обычно человеческое удобное название)


  • notes - поле типа TEXT, для примечаний


  • num - номер чего-либо (может быть числовой либо текстовый, например Письмо N "1234/56-789")


  • ...разумеется, список можно продолжать.


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

    Ставить ли подчеркивание между сущностью и смысловым суффиксом, вроде  street_name - дело вкуса. Это красиво выглядит в статье, но отвратительно в программном коде, потому что в точечной нотации objStreet.Street_Name подчеркивание выглядит как разделитель более высокого уровня, чем точка, и сбивает с толку. Кроме того, подчеркивания плохо видны на некоторых шрифтах и на бумажных распечатках. Поэтому подчеркивания я использую редко. В Pascal достаточно придерживаться общепринятой венгерской нотации - начинать каждое слово с заглавной буквы: StreetName, а в SQL чаще всего пишут ключевые слова большими буквами, идентификаторы - в венгерской нотации или просто маленькими буквами.

    Иногда в нескольких таблицах встречаются служебные поля, не связанные с какой-либо сущностью, а используемые программистом либо базой данных для служебных целей, например поля вроде Row_ID в Oracle. Здесь нужно следить, чтобы имена сущностей не пересекались с названиями таких полей, иначе служебные поля будут ошибочно "мысленно привязаны" к какой-то нашей таблице.


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