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

Question

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

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

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

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

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

Answer 1

Это называется «Hungarian Notation».

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

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

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

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

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

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

5. Важнейшее: оно не содержит никакой полезной документации на , что означает данных. Мой опыт в том, что люди коррумпируют смысл почти всегда. Они редко (если вообще когда-либо) путаются в том, что это int или string; и когда они хотят знать, они просто описывают таблицу, используя TOAD или какой-либо другой инструмент, который дает тип ACTUAL, а не частичное резюме предполагаемого типа.

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

прочитанное Иоиля о Making Wrong Code Look Wrong. Особенно раздел «Я - Венгрия».

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

Мой этос по стандартам кодирования:

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

Cheers. Кит.