Соглашения об именах ненормализованных полей

Question

Является ли обычной практикой использование специальных соглашений об именах, когда вы денормализуете производительность?

Например, допустим, у вас есть таблица customer со столбцом date_of_birth.Затем вы можете добавить столбец age_range, потому что иногда слишком дорого рассчитывать возрастной диапазон этого клиента.Тем не менее, это может показаться запутанным, потому что не совсем понятно, какие значения являются авторитетными, а какие получены.Поэтому, возможно, вы захотите назвать этот столбец denormalized_age_range или как-то еще.

Распространено ли использование специального соглашения об именах для этих столбцов?Если да, существуют ли установленные соглашения об именах для такой вещи?

Редактировать: Вот еще один, более реалистичный пример того, когда денормализация даст вам прирост производительности.Это из реальной жизни.Допустим, вы пишете приложение, которое отслеживает курсы колледжей во всех колледжах в США.Вы должны быть в состоянии показать для каждой степени, сколько кредитов вы получили, если выберете эту степень.Подсчет кредита степени фактически невероятно сложен для вычисления, и это занимает много времени (более одной секунды на степень).Если у вас есть отчет, сравнивающий 100 различных степеней, рассчитывать количество кредитов на лету было бы непрактично.Когда я столкнулся с этой проблемой, я добавил столбец credit_count в нашу таблицу degree и рассчитал количество кредитов для каждой степени.Это решило проблему производительности.

Answer 1

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

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

Answer 2

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

Может быть, суффикс "копия" может быть использован для этого. Потому что, в конце концов, данные - это просто копия какого-то другого места, где хранятся первичные данные. Поскольку это слово, оно может работать со всеми соглашениями об именах, такими как .NET PascalCase, которые могут быть сопоставлены с SQL snake_case, e. г. CompanyIdCopy и company_id_copy. И это короткое слово, поэтому вам не нужно писать слишком много. И это не аббревиатура, поэтому вам не нужно писать это по буквам или задумываться над тем, что это значит. ; -)

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

Слово «производное» немного длиннее, чем «копия». Я знаю, что одна специальная СУБД, дорогая, имеет ограничение имени столбца в 30 символов, так что это может быть проблемой.

Answer 3

В некоторых языках программирования, например Java, имена переменных с префиксом _ используются для частных методов или переменных. Приватный означает, что он не должен изменяться / вызываться никакими методами вне класса.

Интересно, можно ли заимствовать это соглашение в именовании столбцов производной базы данных.

В Postgres имена столбцов могут начинаться с _, например _average_product_price.

Это может передать смысл, что вы можете прочитать этот столбец, но не пишите его, потому что он получен.

Answer 4

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

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