Галерея
7757 8119 8300 8698 8817 9504 9722 9937
Интересные записи
Топовые новости
Новое

Соглашения об именах

Соглашения об именах определяют стандартную основу для выбора идентификатора объекта. В этом разделе мы приводим список соглашений (правил выбора идентификатора), которые основываются на многолетнем опыте. В стандарте SQL ничего не говорится об этих соглашениях, за исключением того, что идентификатор должен быть уникальным, что его длина не должна превышать определенных значений и что все символы в идентификаторе должны быть допустимыми.

Выбирайте имя так, чтобы оно было осмысленным, наглядным и соответствовало назначению объекта.

Не называйте таблицу ХРОЗ, назовите лучше Expenses_2005, чтобы было ясно, что в ней содержатся расходы за 2005 год. Помните, что и другим людям скорее всего придется использовать таблицу и базу данных, и возможно, еще в течение долгого времени после того, как вы уйдете. Имена должны быть понятны с первого взгляда. У каждого производителя есть свои ограничения на длину имени объектов, но, как правило, имена могут быть достаточно длинными, чтобы любой мог понять их смысл. Используйте в именах один и тот же регистр по всей базе.

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

Как только сокращение выбрано, его нужно последовательно использовать по всей базе данных. Например, если вы используете ЕМР как сокращение слова EMPLOYEE, то используйте ЕМР по всей базе данных. Не используйте в одних местах ЕМР, а в других — EMPLOYEE. Для удобства восприятия используйте полные, наглядные и осмысленные имена с символами подчеркивания

Имя столбца UPPERCASEWITHLNDERSCORES не такое понятное, как UPPERCASEJWITHUNDERSCORES.

Не помещайте название компании и продуктов в имена объектов баз данных.

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

Не используйте слишком очевидные префиксы и суффиксы.

Например, не используйте в качестве префикса имени базы данных сочетание «DB_», а в качестве префикса всех представлений — «V_». Простые запросы к системным таблицам базы могут дать администратору или программисту базы сведения о том, к какому типу относится объект, который представляет идентификатор.

Не заполняйте все пространство, отведенное для имени объекта.

Если платформа позволяет использовать имя таблицы из 32 символов, попробуйте оставить хотя бы несколько пустых мест в конце. Некоторые платформы при манипуляции временными копиями таблиц иногда добавляют к именам таблиц пре-фиксы и суффиксы.

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

Иногда имена объектов заключают в двойные кавычки. (Стандарт ANSI называет такие имена идентификаторами с разделителями (delimited identifier!, -). Такое заключение идентификатора в кавычки позволяет создавать имена, которые могут оказаться сложными в использовании и которые впоследствии могут вызывать проблемы. Такие идентификаторы чувствительны к регистру. Например, вы можете включать в них пробелы, специальные символы, символы в разных регистрах и даже управляющие символы. Однако, поскольку некоторые инструменты, выпускаемые сторонними производителями (и даже производителем самой базы), могут не обрабатывать специальные символы в именах, широко использовать подобные идентификаторы не следует. Некоторые платформы разрешают использовать другие символы-ограничители, помимо двойных кавычек. Например, в SQL Server для обозначения идентификаторов с ограничителями применяются квадратные скобки [].

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

Источник