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

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

Кто-нибудь на самом деле знает, почему этот размер не больше - или он больше в 11g?

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

Всякий раз, когда я вижу подобные возражения внутри компании, я думаю, что пришло время кусать пулю и разбираться с ней. Если люди запускают сценарии, которые они не проверяют или не поддерживают при обновлении версий Oracle, пусть они пострадают от последствий этого выбора. Предоставьте им флаг совместимости, увеличьте его до 4000, а затем сэкономьте время, потраченное на создание объектов, так как мне приходится постоянно считать до 30, чтобы проверить, что имя «ОК».

Я считаю, что это стандарт ANSI.

РЕДАКТИРОВАТЬ:

На самом деле, я думаю, что это стандарт SQL-92.

Более поздняя версия стандарта, по-видимому, допускает возможность использования 128-символьных имен, но Oracle пока не поддерживает это (или имеет частичную поддержку, поскольку допускает 30 символов. Хммм.)

Ищите «F391, Длинные идентификаторы» на этой странице ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Ищу реф)

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

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

внезапно сломаться, потому что администратор базы данных 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 )

В какой-то момент каждый администратор базы данных или разработчик достигнет точки, когда ограничение в 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).

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

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

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

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

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

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

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

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

Все вышеприведенные комментарии верны, НО вам нужно помнить о стоимости производительности длинных имен. В начале 1990-х годов, когда Informix установил огромный рекламный щит "Informix Faster Than 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