Почему имена таблиц / столбцов / индексов 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 в script, вызвал бы массовый бунт. Я бы сделал ставку на то, что в Oracle только тысячи мест, где такие вещи делались на протяжении многих лет в различных пакетах и ​​компонентах. Повторная настройка всего этого существующего кода для поддержки более длинных идентификаторов будет огромным проектом, который почти наверняка приведет к увеличению затрат в течение времени разработки, времени QA и новых ошибок, чем при создании преимуществ.

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

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

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

Изменить: Здесь ссылка на официальную документацию 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).

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

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

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

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

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

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

Это оставляет слой базы данных администратору баз данных и архитекторов данных, которые, возможно, не беспокоились. Кажется, разработка схем сокращения - это пожизненная работа.

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

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

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

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

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

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