Поскольку ключевое поле — это обычное поле таблицы, то на него распространяются все рекомендации приведенные в разделе «Поля таблицы». Однако поскольку это все-таки очень специфическое поле, то для него я бы добавил следующие рекомендации
Образуйте название ключевого поля таблицы добавив к имени таблицы 2 буквы «ID» (от слова identifier — идентификатор), отбросив букву «s» если имя таблицы — это слово во множественном числе — Например, если вы назвали таблицу контрагентов «Partners», то ключевое поле будет назваться «PartnerID». При таком способе наименования однозначно можно сказать к какой таблице относится ключевое. Но не стоит назвать ключевое поле также как и собственно таблицу, поскольку в некоторых случаях станет весьма проблематично сходу определить о чем идет речь — о поле или собственно о таблице
Называйте внешние ключи также как и соответствующие ключевые поля — такой способ наименования внешних ключей очень облегчает понимание о чем собственно идет речь при написании программы.
Ограничивайте название ключевого поля 10 символами — причина здесь в том, что количество символов в названии индексного тэга не может быть больше 10. А по ключевому полю обязательно следует построить индекс. Если количество символов в ключевом поле будет больше 10, то название индексного тэга будет отличаться от названия ключевого поля. А это не очень хорошо в том смысле, что серьезно затруднит программирование, поскольку использовать этот индекс Вы будете сплошь и рядом.
Кстати, из этой рекомендации вместе с самой первой рекомендацией по наименованию ключевых полей вытекает, что количество символов в имени таблицы не должно превышать 8 (или 9, если название таблицы — это множественное число)
Собственно работа с ключевыми полями таблицы
Значение ключевого поля должно присваиваться один раз в момент создания записи и не меняться все время существования этой записи. Крайне нежелательно модифицировать значение ключевого поля. Лучше строить программу таким образом, чтобы не возникало необходимости в подобной модификации. Более того, я бы не рекомендовал использовать значения ключевых полей удаленных записей (умерла, так умерла).
Такая стратегия сильно облегчает отлов ошибок пользователей, поскольку в большинстве случаев, если пользователь делает ошибку в документе, то он не исправляет ошибочный документ, а удаляет его и создает заново! Вот и докажи потом, что это не программа плохая!
Кроме того, такая стратегия позволяет с меньшими проблемами интегрировать несколько баз данных в один комплекс если в этом возникает необходимость.
Ни в коем случае не давайте пользователям возможность самостоятельно изменять значение ключевых полей. Более того, пользователь вообще не должен подозревать об их существовании. Это должен быть исключительно внутренний механизм обеспечения целостности базы данных.
Дело в том, что любая информация, которую вводит пользователь по определению является не надежной и как бы Вы ни защищали информацию, пользователь найдет как ее обойти или просто заставит Вас это сделать! А то, о чем он не подозревает и испортить не может.
Не пытайтесь навесить на ключевые поля какие-либо еще функции кроме однозначной идентификации записи.
Например, в некоторых случаях возникает соблазн использовать ключевые поля еще и как порядковый номер элемента в списке. Так вот, не надо этого делать. Введите для реализации этой функциональности дополнительное поле. Также не следует использовать ключевое поле, как краткое название элемента
Если Вы навесите на ключевое поле еще какую-либо функциональность, кроме однозначной идентификации записей, то просто создадите себе массу проблем (сильно усложнится программный код). А в качестве преимуществ только некоторая экономия дискового пространства. Думаю, оно того не стоит.
