Есть ли причина использовать чрезвычайно сокращенные имена таблиц?


22

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

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

Насколько я знаю, длина имени таблицы заметно не повлияет на производительность, верно? База данных очень сложна (сотни таблиц), поэтому сортировка имеет смысл, но я не могу себе представить, почему AccountsPayableTransactions не предпочтительнее aptrx ....


8
кому-то не ударили в затылок достаточно сильно, чтобы узнать лучше
DForck42

2
* ухмыляется * это для безопасности работы, стоимость увольнения старых программистов и найма новых становится намного выше, если у вас есть загадочные имена.
Ли Райан

@Lie_Ryan, что, безусловно, имеет место, что они будут надеяться, что вы наймете консультанта ...
Бен Брока

FWIW, если вы работаете в системах бухгалтерского учета, «aptrx» не является загадочным. Это очевидно. Более подробно в моем ответе ниже.
Майк Шеррилл 'Cat Recall'

запутывание является одной из причин
Арно Ле Блан

Ответы:


23

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

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


2
Если 30 символов недостаточно для того, чтобы составить уникальные имена для таблиц, у вас есть гораздо более серьезная проблема, чем любая СУБД или среда разработки: у вас есть проблема с уровнем выразительности вашего языка и / или словарь.
Эрвин Смут

18

Я чувствую, что есть две вещи, которые еще нужно сказать или разработать:

  1. Называть вещи не так тривиально, как кажется

    В Computer Science есть только две серьезные проблемы: аннулирование кэша и присвоение имен. Фил Карлтон

  2. Хотя короткие бессмысленные имена всегда плохи, длинные имена не всегда хороши - у нашего мозга есть встроенный порог tl; dr, который удивительно низок. 30 символов обычно достаточно, но я предпочитаю, чтобы СУБД позволяла больше для исключительных случаев, когда это не так (и, как и в языке, более длинные имена более полезны для вещей, о которых мы не говорим так часто - например, имена ограничений, и более короткие имена более полезны для таблиц, которые мы запрашиваем постоянно)

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


2
Я очень разборчив в именах, и моя текущая ограниченная способность менять их не дает мне покоя. Я в UX, хотя, поэтому неиспользуемые имена могут особенно меня беспокоить. Плюс я просто предпочитаю CamelCase ...
Бен Брока

7

Лень. Возможности IntelliSense и сторонних производителей делают ввод текста очень сложным оправданием. Я бы предпочел, чтобы в именах были значимые и читаемые слова.


6

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

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

Аббревиатуры сохраняют место на платформах, которые имеют жесткие ограничения, хотя сейчас это менее важно, чем 30 лет назад. (Кажется, я помню, как работал над системой в 1980-х годах, которая ограничивала вас 6 или 8 символами для названия таблицы.)

Сокращения обычно облегчают чтение имен таблиц и столбцов, если сокращение выполняется хорошо. Если бы я работал над кодом для AP весь день, я бы предпочел читать имена столбцов, такие как «ap_trx.inv_num», а не «account_payable_transactions.invoice_number». (Мне нравятся подчеркивания.) Ввод длинных имен не составляет большой проблемы с хорошим текстовым редактором.

В учетных системах как «ap», так и «trx» являются общеизвестными сокращениями. Другие включают «ar», «gl» и «gj» для дебиторской задолженности, главной книги и общего журнала.

В хорошо спроектированной системе, если бы я нашел транзакции кредиторской задолженности в таблице с именем «aptrx», я бы надеялся найти транзакции дебиторской задолженности в artrx, транзакции Главной книги в gltrx и так далее. Я нахожу «apmaster_all» немного озадачивающим, но если бы я также нашел «armaster_all», я бы предположил, что первый содержал всех поставщиков (в отличие от активных или неактивных продавцов), а второй аналогичным образом содержал всех покупателей.

В других проблемных областях вы найдете другие известные сокращения. При адресации вы найдете такие сокращения, как «addr» для адреса, «st» для улицы, «usps» для почтовой службы США, «ups» для United Parcel Service, «cty» для округа, «zip» для улучшения зоны Код и тд.

Я бы не назвал это запутыванием. Если бы транзакции кредиторской задолженности хранились в таблице с именем «cdrs21», я бы назвал это обфускацией. (Хотя однажды я работал в компании, которая так назвала все свои модули ассемблера мэйнфреймов. Ограничения символов, а не запутывание.)

Но полезные базы данных растут, и вы сталкиваетесь с проблемой, когда базы данных становятся большими. Когда вы добавляете проблемные домены в свою базу данных, вы сталкиваетесь с ситуациями, когда сталкиваются известные сокращения. Если вы имеете дело со средствами массовой информации, тогда «ap» может также сокращать «Associated Press», «альтернативная пресса» или «предварительное размещение». Когда это произойдет, пора либо отказаться от сокращений, либо перейти на коды. Чем больше организация (и чем больше база данных), тем чаще я нахожу коды.


4
Частично проблема заключается в том, что эти таблицы не обслуживаются бухгалтерами, они обслуживаются системным аналитиком, и, как правило, наш ИТ-отдел aptrx на самом деле является одним из самых логичных имен, которые я нашел, одним из немногих, которые я «ве вспомнил . Также обратите внимание, что есть несколько сотен таблиц; основные аббревиатуры, такие как «ap» для «кредиторской задолженности», очень легко выучить, буквально 100 суффиксов после «ap» не являются ...
Бен Брока

4

Просто повторяю «мой бог, очки, которые они ничего не делают для этой ужасной истории именования». Команда управления данными в моей последней среде заявила, что причиной использования сокращенных имен таблиц было ограничение DB2 (у нас была DB2 на z / os и SQL Server) в 18 символов для таблиц и столбцов. Я быстро указал, что это было неточно с документацией с сайта IBM. Затем они заявили, что это была проблема с COBOL (да, они активно разрабатывались на COBOL) на случай, если необходимо поговорить с базой данных, которая затем была опровергнута жокеями MF. Наконец, их ответ был нашим стандартом публикации.

Мы обратились в комитет по стандартам с просьбой увеличить длину с 18 до 32 символов и получили ограничение в 30 символов. Это привело к тому, что таблицы перешли от бесполезных имен 'SR_M_DLY_ADV_PRD_S' к 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

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


1
кажется, что имена переходят от совершенно бесполезных имен к чуть менее бесполезным именам. Возможно, нормализация может помочь? Если каждая таблица делает меньше, то есть меньше причин иметь длинные имена из нескольких слов, поэтому меньше причин для сокращения.
Ли Райан

На самом деле, этот отвратительно длинный стол не смог бы сделать меньше, если бы попытался. В нем 4 столбца, 2 из которых были внешними ключами. Это таблица «возврата статистики» для всех, кроме тех, кто защищает священные данные словарей знаний. Там есть таблица перекрестных ссылок статистики доходности классов акций индекса.
billinkc

ты просто взорвал мой разум этим; возможно, я просто незнаком с проблемной областью, но таблица не сразу очевидна для меня, даже после того, как я увидел не сокращенное имя. Несколько вопросов в моей голове (просто список вещей, которые не были очевидны для меня сразу, вам не нужно отвечать на них, если вы не хотите): это таблица сущностей или таблица отношений? «Индекс» имеет какое-либо отношение к «индексу базы данных»? По "перекрестным ссылкам" и "статистике возврата" мне кажется, что это намекает на ненормализованную таблицу агрегирования (которая может быть полезна при их вычислении, дорогая)?
Ложь Райан

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

3

Это привычка (я согласен с Кевинским). Это была реакция на некоторые старые (возможно, существующие) проблемы на ограничение (длина имени, пробел между словами сложных имен, многоязычность и т. Д.) Операционной системы (например, DOS, Windows) и некоторых программ, которые не обрабатывали такие имена. Опытные люди говорили: «Делайте так (используйте короткие и разделенные именами подчеркивания), и все будет хорошо».


2

Мне нравится использовать описательные названия по вышеупомянутым причинам постерами.

Но есть и еще одно преимущество. Например, с описательным наименованием, это позволяет вам использовать вложенные имена. Скажем, у вас есть стол под названием Сотрудник. Если у вас есть отношение к другой таблице, она может называться EmployeeAddress. Или сотрудник отдела. С загадочным, сокращенным наименованием это практически невозможно.


0

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


Поскольку таблицы не содержат неавтоматических метаданных, я не уверен, что это правильный аргумент ...
Бен Брока
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.