Почему имена таблиц/столбцов/индексов Oracle ограничены 30 символами?

в дополнение к точке cagcowboy, что она происходит от стандарта SQL (исторически я подозреваю, что решение Oracle приводит к стандарту SQL, поскольку Oracle предшествовала стандартизации SQL), я бы поставил, что большая часть нежелания разрешать более длинные идентификаторы происходит от осознания того, что существуют миллионы баз данных с миллионами пользовательских скриптов, которые все предполагают, что идентификаторы имеют длину 30 символов. Разрешение каждой строки кода, которая идет что-то как

  l_table_name VARCHAR2(30);
BEGIN
  SELECT table_name
    INTO l_table_name
    FROM dba_tables
   WHERE ...

внезапно сломаться, потому что DBA 15 лет назад использовал VARCHAR2(30), а не DBA_TABLES.TABLE_NAME%TYPE в сценарии вызовет массовый бунт. Я бы поспорил, что только Oracle имеет тысячи мест, где подобные вещи были сделаны на протяжении многих лет в различных пакетах и компонентах. Модернизация всего этого существующего кода для поддержки более длинных идентификаторов будет огромным проектом, который почти наверняка создаст путь больше затрат во времени разработчика, QA время, и вновь появляются ошибки, чем принести пользу.

Я искал это и нашел этот вопрос через Google, но также узнал, что по состоянию на Oracle 12c Release 2 (12.2) это уже не строго так. (https://oracle-base.com/articles/12c/long-identifiers-12cr2)

в какой-то момент каждый DBA или разработчик попадет в точку, где ограничение 30 символов для имен объектов вызвало проблему. Это ограничение может быть чрезвычайно болезненным при выполнении проектов миграции из SQL Server или MySQL в Oracle. В базе данных Oracle 12cR2 максимальная длина большинства идентификаторов теперь составляет 128 символов.

Это новая функция в 12.2, согласно (http://blog.dbi-services.com/oracle-12cr2-long-identifiers/). Согласно этому сообщению, 12.1 все еще был ограничен 30 символами.

---

Edit: вот ссылка на официальную документацию Oracle, объясняющую это изменение. (https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C)

начиная с Oracle Database 12c Release 2 (12.2), максимальная длина имен идентификаторов для большинства типов объектов базы данных была увеличена до 128 байт.

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

например, соглашение об именовании ограничений внешнего ключа

FK_<table1>_<table2> 

ограничивает имена таблиц до 13 символов или менее; большинству баз данных потребуется больше префиксов и суффиксов, что еще больше ограничивает длину имен таблиц.

о нарушениях ограничений сообщается в SQLERRM, который ограничен 255 символами и который большинство клиентов используют для отображения ошибок. Я подозреваю, что увеличение допустимого размера имен ограничений значительно повлияет на возможность сообщать о нарушениях (особенно если нарушение ограничений было вызвано несколькими слоями кода PL/SQL).

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

все эти "ограничения" остаются над ответами на ограничения, наложенные процессорными архитектурами, которые родом из 70-х годов. С тех пор процессоры эволюционировали до такой степени, что эти ограничения больше не нужны; они просто остаются. Однако изменение их-это большое дело для авторов РСУБД. Поскольку эти ограничения длины влияют на все вниз по течению, меняя его волей-неволей, чтобы разместить, скажем, более длинное имя процедуры может и, вероятно, сломает много других такие вещи, как exeception reporting, словарь данных и т. д. и так далее и так далее. Я бы потребовал серьезной переписать СУБД Oracle.

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

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

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

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

Это оставляет уровень базы данных для DBA и команд архитекторов данных, которые, возможно, не беспокоятся. Разработка схем сокращения все еще является работа на всю жизнь, кажется.

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

все вышеперечисленные комментарии верны, но вам нужно иметь в виду стоимость производительности более длинных имен. В начале 1990-х, когда Informix установил огромный рекламный щит "Informix быстрее Oracle!"по маршруту № 101 рядом с штаб-квартиры корпорации Oracle, Informix и разрешила имена таблиц, только короче, чем 18 символов! Причина очевидна - имена таблиц в их буквальной форме (т. е. как фактические имена, а не 't138577321' или что-то в этом роде) хранятся в словаре данных. Более длинные имена равны большему Словарь данных, и поскольку словарь данных читается каждый раз, когда запрос требует жесткого анализа, больший словарь данных равен низкой производительности...

ОК, ограничение существует....

но вам действительно нужно больше, чем до 30 символов, чтобы назвать таблицу/индекс/столбец??

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

select unique_identifier_column, 
time_when_the_user_remembered_to_change_the_row_in_the_receipt_table, 
foreign_key_to_the_ap_invoice_distributions_history_table_related_to_the_all_rows_table 
from ap_invoices_really_really_all_all_rows_present_in_this_ebs_table.

прошу прощения за огромные слова: P