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

в дополнение к точке cagcowboy, что она происходит от стандарта SQL (исторически я подозреваю, что решение Oracle привело к стандарту SQL, так как Oracle предшествовала стандартизации SQL), я бы поспорил, что большая часть нежелания разрешать более длинные идентификаторы происходит от осознания того, что есть миллионы DBAs с миллионами пользовательских скриптов, которые все предполагают, что идентификаторы имеют длину 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 Database 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" или что-то в этом роде) хранятся в словаре данных. Длинные имена равны большим Словарь данных, а так как словарь данных читается каждый раз, когда запрос требует жесткого анализа, большой словарь данных равен низкой производительности...

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

но вам действительно нужно больше, чем 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