Мы используем настройку базы данных из приложения поставщика, которое ужасно трудно читать имена таблиц базы данных, и нет документации о том, что и где хранится. Я понимаю, почему кто-то может захотеть запутать структуру их таблиц в проприетарном приложении, но одним из преимуществ этого приложения (Планирование ресурсов предприятия) была его настраиваемость.
Имена таблиц похожи на aptrx (транзакции кредиторской задолженности) и apmaster_all (что любопытно, это таблица поставщиков). Это чрезвычайно сложная база данных, поэтому мне было интересно, есть ли какая-либо логика в соглашении или она просто запутывается намеренно или иным образом.
Насколько я знаю, длина имени таблицы заметно не повлияет на производительность, верно? База данных очень сложна (сотни таблиц), поэтому сортировка имеет смысл, но я не могу себе представить, почему AccountsPayableTransactions не предпочтительнее aptrx ....
источник
Ответы:
В Oracle давно существует ограничение на имена таблиц в 30 символов. Я подозреваю, что это устаревшая проблема, основанная на оригинальной 16-битной среде.
Длина имени таблицы может оказать незначительное влияние на производительность, поскольку все имена должны храниться в словаре данных, а также анализироваться для запросов, но я не думаю, что вы могли бы измерить попадание.
Более важным эффектом коротких имен таблиц является то, что с ними трудно работать. Я тоже должен поддерживать схему корпоративной базы данных с короткими именами. Нет веской причины иметь короткие имена таблиц. Легкость в обслуживании превосходит запутывание или старые привычки DOS каждый раз.
источник
Я чувствую, что есть две вещи, которые еще нужно сказать или разработать:
Я всегда испытываю соблазн тратить слишком мало времени на выбор имен и всегда сожалею об этом позже, если я это сделаю - смена имен происходит очень редко
источник
Лень. Возможности IntelliSense и сторонних производителей делают ввод текста очень сложным оправданием. Я бы предпочел, чтобы в именах были значимые и читаемые слова.
источник
Хорошо известные сокращения обычно предпочтительнее изложения. Когда аббревиатура известна некоторым людям, но их недостаточно, мы перестаем называть ее аббревиатурой и начинаем называть ее кодом.
Аббревиатуры сохраняют место на платформах, которые имеют жесткие ограничения, хотя сейчас это менее важно, чем 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», «альтернативная пресса» или «предварительное размещение». Когда это произойдет, пора либо отказаться от сокращений, либо перейти на коды. Чем больше организация (и чем больше база данных), тем чаще я нахожу коды.
источник
Просто повторяю «мой бог, очки, которые они ничего не делают для этой ужасной истории именования». Команда управления данными в моей последней среде заявила, что причиной использования сокращенных имен таблиц было ограничение 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
Итак, за мой десяток лет опыта сокращенные имена таблиц не дают ощутимых преимуществ и приводят к более высокой стоимости разработки и обслуживания, поскольку я всегда должен обращаться к словарям данных, чтобы перевести мусор на экране в значимый идентификатор. Это можно сравнить с логически названными сущностями, с которыми я работал, и в основном можно воссоздать из памяти, потому что они были интуитивно названы.
источник
Это привычка (я согласен с Кевинским). Это была реакция на некоторые старые (возможно, существующие) проблемы на ограничение (длина имени, пробел между словами сложных имен, многоязычность и т. Д.) Операционной системы (например, DOS, Windows) и некоторых программ, которые не обрабатывали такие имена. Опытные люди говорили: «Делайте так (используйте короткие и разделенные именами подчеркивания), и все будет хорошо».
источник
Мне нравится использовать описательные названия по вышеупомянутым причинам постерами.
Но есть и еще одно преимущество. Например, с описательным наименованием, это позволяет вам использовать вложенные имена. Скажем, у вас есть стол под названием Сотрудник. Если у вас есть отношение к другой таблице, она может называться EmployeeAddress. Или сотрудник отдела. С загадочным, сокращенным наименованием это практически невозможно.
источник
Зависит от того, насколько сложны базовые определения каждого столбца. Я думаю, что люди становятся ленивыми в управлении метаданными, когда видят очень описательные имена столбцов, и они даже являются неполными описаниями. С таким же успехом вы можете спросить, зачем что-то сокращать.
источник