Префикс типа столбцов базы данных

Question

Я разработка решений с базами данными для более чем 11 лет, и, кажется, я «разработал» довольно спорное мнение о именовании столбцов в моих таблицах: я всегда даю им префикс типа 3 или 4 символа, то есть intGroupID, nvcTitle, dtmCreated, bitPlayerHater и т. д. Я работал с несколькими другими разработчиками, которые абсолютно презирали соглашение о префиксах старой школы.

(да, я знаю, я ничего здесь не изобретал, я просто отказываюсь от этого отказываться:)

Моя основная причина - предоставить как можно больше информации моим коллегам-разработчикам, когда они пытаются понять структуру данных. Знание типа столбцов мгновенно дает вам (или мне, по крайней мере) лучшее представление о том, с чем вы имеете дело. И, как правило, при написании запросов вы не получаете такую ​​же поддержку intellisense из среды IDE, как при работе с C # или VB.NET.

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

Почему префикс столбцов базы данных считается плохой практикой?

Answer 1

Это называется " Венгерская запись ".

Как разработчик (и архитектор данных), я нахожу это бесполезным. Это не дает много информации.

1. Это обеспечивает только быстрый, неточный блеск для части информации о типе. Например, длина не указана.

   В более сложных средах баз данных, где объектами являются BLOB-объекты, он вообще не предоставляет никакой информации о типе объекта в BLOB-объекте.

2. Это делает изменение типа данных болезненным.

3. Необходимо запомнить неясный префикс. Это vcName, strName или uniName?

4. SQL автоматически обрабатывает преобразования типов, делая суетливое именование, специфичное для типа, в значительной степени неуместным.

5. Самое важное: не предоставляет полезной документации по , что означает данных. Мой опыт показывает, что люди почти всегда портят смысл. Они редко (если вообще когда-либо) путаются в том, является ли это int или string; и когда они хотят знать, они просто описывают таблицу, используя TOAD или другой инструмент, который дает ФАКТИЧЕСКИЙ тип, а не частичную сводку предполагаемого типа.

[Сказав, что это примерно бесполезно, я понимаю, что это, вероятно, не тот «убийственный аргумент», который вы ищете. Было бы полезно, если бы вы могли дополнить свой вопрос точными точками, которые, по вашему мнению, являются ценностью венгерской нотации, поэтому они могут быть рассмотрены по точкам.]

Answer 2

Я несколько раз менял типы столбцов. Например, code от number до string. Без префиксов я могу сделать это без перекодирования в большинстве случаев, и все приложения все равно будут работать (по крайней мере, в Oracle). С вашим методом мне нужно изменить intCode на strCode, и я на 100% уверен, что мне нужно повторить весь мой код, используя это поле!

То же самое верно для замены целого числа на число с плавающей точкой.

Некоторые люди также добавляют префиксы к именам столбцов (например, department.dep_code). Я нахожу это действительно трудным для написания кода, поскольку я склонен забывать аббревиатуры. Система с 50 таблицами имеет тенденцию получать очень похожие префиксы. Причиной его использования является то, что при объединении сотрудника с отделом поле кода отдела является уникальным (emp_code и dep_code). Я не думаю, что это повышает ценность, поскольку это можно сделать проще, используя псевдонимы таблиц, которые не заставляют вас использовать префикс.

Я часто использовал префиксы в своем клиентском коде для компонентов GUI. Например. sle для однострочного редактирования, а также венгерская запись для c и powerbuilder. При переходе на java я перестал им пользоваться. Я думаю, что я использовал более четкие имена для моих переменных. Однако переход к объектно-ориентированным языкам заключается в том, что все является объектом, и немного глупо использовать objVariable везде.

Answer 3

Моя самая большая причина, по которой имена столбцов не префиксируются, заключается в том, что они имеют тенденцию значительно дольше обрабатывать мои запросы, когда мне приходится запоминать (а затем вводить) префикс моих столбцов вместо простого логическое имя (например, FirstName вместо strFirstName).

Answer 4

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

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

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

Если они продолжают ныть, отправь их мне. Я дам им что-то реальное, чтобы разозлиться, например, PascalCase в Java-программе или некапитализированные CONSTANTS, например; -)

В качестве отступления: я также перенес стандарт Java для именования элементов управления (и только элементов управления) в Java, потому что он имеет смысл и представляет полезную информацию; и он настолько широко известен и используется, что служит языком общения, даже если он идет вразрез со стандартами кодирования Java.

Мой идеал о стандартах кодирования:

• Делай, что работает.
• Прочитайте и поймите хотя бы один опубликованный стандарт, но не следуйте ему догматично. См. Пункт 1.
• Когда в Риме ... последовательность - это ключ к тому, чтобы заставить его «держаться вместе». См. Пункт 1.

Приветствия. Кит.

Answer 5

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

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

Одна веская причина не использовать префиксы: это затруднит выполнение запросов к словарю данных, отсортированному по идентификатору, поскольку теперь ведущая часть идентификатора действительно является типом. На мой взгляд, тип является отличным от идентификатора свойством и поэтому должен храниться отдельно.

Answer 6

Кроме того, если вам когда-либо придется изменить тип данных (это происходит чаще, чем вы думаете - мы только что перешли на юникод), вам придется менять имена столбцов по всему коду. (это плохо, кстати!): -)

Answer 7

Проблема заключается в так называемой нотации венгерских приложений и нотации венгерских систем. Первый добавляет информацию о виде данных, которые у вас есть (например, dx может означать «количество пикселей от левой границы»), а второй добавляет информацию о типе данных у вас есть (например, bit, чтобы означать bit).

В современных средах и методах программирования вам никогда не придется искать, с какой тип переменной вы работаете. IDE и компилятор сообщат вам, если вы не правы. Так что это по существу избыточные данные, которые начинают мешать вам, когда вы начинаете (автоматически) генерировать источник по этим именам:

// just looks wrong:
public void SetSomething(bool bitPlayerHater)

Прочитайте статью Джоэла о Как сделать неправильный код неправильным . Особенно в разделе «Я Венгрия».

Answer 8

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

Что касается работы в визуальной IDE, я видел много магазинов, которые не предписывают называть объекты (текстовые поля, комбинированные списки и т. Д.) По общему соглашению. Поскольку многие вещи, которые я исторически делал, динамически генерируются, связаны, связаны, я использую такой префикс для элементов управления, таких как txtFirstName, btnOk, cboStateList и т. Д. Затем, элементы управления, я удаляю первые 3 символа и называю поле (если применимо) для автоматического связывания во время выполнения с объектом данных. Однако, как указано выше, префикс имен столбцов в таблице может вызвать больше проблем, чем помогает.

Только ценность моего доллара (инфляция от 2 центов)