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

149

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

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


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

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

Крис Гилл
источник
3
Так как должен быть предел? Сделайте это 64 символами, и вы, вероятно, найдете кого-то, спрашивающего, почему это не 128 и т.д.
Председатель
45
Правда, но 30 - это очень короткий кусок строки. Почему это не может быть 4000 - размер Varchar2 - действительно ли Oracle заботится о том, сколько времени прошло после анализа запроса?
Крис Гилл
22
@TheChairman PostgreSQL ограничивает меня до 63 символов, и у меня никогда не было проблем с этим ограничением длины. Он достаточно большой, чтобы мои имена подходили, и если я подумываю над более длинным именем, пришло время задуматься о негативном влиянии на читабельность. С другой стороны, я часто сталкиваюсь с ограничениями длины имени в Oracle и вынужден уменьшить читабельность моего имени из-за ограничения в 30 символов. Несколько человек могут жаловаться на ограничение в 64, но у многих уже есть проблемы из-за ограничения в 30 символов. Речь идет о соблюдении 99% вариантов использования, и Oracle терпит неудачу здесь.
jpmc26
1
Давай, Оракул, ты стал Динозавром! Microsoft делает хорошую работу, чтобы сделать SQL-сервер более дружественным. Теперь ослабьте ограничение длины имени.
user3454439
1
Перенесемся в Oracle 12cR2, теперь 128 байтов вместо 30 :-) docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/…
Стефан Л

Ответы:

71

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

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

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

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

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

(Ищу реф)

cagcowboy
источник
1
Хм, я не так читал этот документ. Он говорит мне, что F391 - это элемент в спецификации SQL / Foundation (что бы это ни было), и что Oracle имеет его частичную поддержку с ограничением в 30 символов.
Скаффман
21
Частично соблюдение. Ну и шутка. «Наши винты частично соответствуют метрическим стандартам, за исключением того, что они не метрические».
Йенс Шаудер
5
Я не читал детально спецификацию F391, но я предполагаю (возможно, неправильно), что «Длинные идентификаторы» означают увеличение длины идентификатора с 30 до 128. Таким образом, сказать, что вы «частично» поддерживаете это, разрешив 30 символов, немного дерзкий Вы не поддерживаете новый стандарт, вы все еще поддерживаете старый стандарт (хотя 25% пути к новому стандарту). Это имело смысл? !!?
cagcowboy
7
Стандарт SQL-92 приведен здесь contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt , но если вы читаете раздел «17.1 Описание областей дескрипторов элементов SQL», он говорит, что идентификаторы, такие как имена и схемы, должны разрешать не менее 128 персонажи.
Рик
46
Тот факт, что фанаты Oracle не видят полезности более 30 идентификаторов символов, вызывает беспокойство. Msgstr "Сделайте ваши имена значимыми / описательными, используйте подчеркивание вместо верблюжьего падежа и оставайтесь длиной до 30 символов". Это никогда не будет более 30 символов. Amirite? Больше похоже на сокращение ваших сокращений, и когда ни одно из названий не имеет смысла, потратьте весь день на чтение / обновление документации.
Адам Джонс
45

В дополнение к утверждению 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 время, и вновь введенные ошибки , чем это было бы генерировать выгоды.

Джастин Кейв
источник
13
+1 Это почти наверняка один из многих уродливых уродов Oracle.
Скаффман
43
Конечно, пришло время вырастить пару и увеличить ее - добавьте флаг, чтобы администраторы баз данных могли довести его до 30. Устаревшие проблемы, такие как эта, всегда должны решаться и сортироваться, иначе вы в конечном итоге нанесете вред всей базе кода, и люди просто переместятся на что-то еще
Крис Гилл
6
Не только миллионы строк кода, написанного для DBA, но и множество внутреннего кода оракула, без сомнения тоже. Эта тема возникла на сессии со Стивеном Фюрштайном, и он сказал, что не думает, что они когда-нибудь это изменят.
Мэтью Уотсон
10
Они не могли точно назвать это новой функцией, они ... они потратили бы много времени на расширение лимита, а затем объявили: «Теперь вы можете использовать имена длиннее 30 символов!». Они были бы посмешищем.
Скаффман
9
Если вы все еще используете 15-летние сценарии, что-то крайне неправильно . Кроме того, их исправление будет стоить единовременно (возможно, с некоторыми дополнительными затратами на дальнейшее обслуживание), в то время как разработчики будут продолжать тратить время на ненужное создание ужасно сокращенных имен до бесконечности. @skaffman Они уже стали посмешищем для того, чтобы не исправлять это (и множество других дизайнерских решений, которые жалки в современную эпоху, например, без булевых или автоинкрементных типов), насколько я понимаю.
jpmc26
11

Я искал это и нашел этот вопрос через 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 байтов.

Kanmuri
источник
128 байтов / 4 байта (Unicode) = 32 символа. По крайней мере, я понимаю, что 4 байта для символов, отличных от Юникода, не так уж редки? Я должен задаться вопросом, означает ли это, что они поддерживают Unicode сейчас? Так же, как VARCHAR2(2)не означает 2 символа, но 2 байта.
Сет
1
Я понимаю вашу точку зрения, но символы против байтов зависят от набора символов вашей базы данных. Этот параметр определяет кодировку для типов данных char (например, varchar2), а также кодировку для идентификаторов БД. Это контрастирует с национальным набором символов, который используется для типов данных nchar. Так что да, если у вас есть кодировка, такая, что ваши идентификаторы используют 4 байта на символ (при условии, что они могут использоваться в качестве набора символов БД), теперь у вас будет 32 вместо 7. Но я думаю, что для большинства вариантов использования идентификаторы будут однобайтовые символы.
Канмури
6

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

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

FK_<table1>_<table2> 

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

Лоренцо Гатти
источник
5

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

Гэри Майерс
источник
Итак, сделайте этот стол шире?
Скаффман
2
Это не таблица, а то, как клиентское программное обеспечение на самом деле получает ошибки из базы данных.
Гэри Майерс
@skaffman Длина SQLERRM - это спецификация API / ABI. Изменение этого означало бы необходимость исправления каждого драйвера OCI на планете (иначе переполнение буфера). Они могли бы внести изменения в клиента, чтобы сначала увеличить buflen в OCI 13 и сервер в чем-то вроде Oracle 15, где клиенты OCI 10 больше не будут поддерживаться, я полагаю. (Может быть, они даже рассматривают это сейчас, но основная версия oracle выпускается только каждые несколько лет; и тогда мы все равно можем столкнуться с проблемой обновления сценариев / приложений, когда приложения переносятся на другой сервер / клиент).
Cowbert
4

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

Майкл Диллон
источник
5
Я полагаю, что первая версия Oracle была написана на Фортране, которая, я думаю, имеет ограничение длины идентификатора 31. Возможно, это уместно.
Дэвид Олдридж
4

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

макинтош
источник
2

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

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

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

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

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

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

atconsul
источник
Не для Oracle. ODBC - это детище Microsoft, а не Java. Это по- прежнему отдельная вспомогательная библиотека, связанная с OCI (посмотрите, как развертывается InstantClient - для работы ODBC с InstantClient необходимы драйвер OCI и почтовые индексы ODBC InstantClient). Основной клиентской платформой Oracle (кроме устаревшей Pro * C / C / C ++) является JDBC, которая напрямую связана с OCI, а не ODBC.
Cowbert
1

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

Рафаэль
источник
7
Нет абсолютно никаких причин для того, чтобы точное сопоставление коротких строк было узким местом в любом современном программном обеспечении, если вы не делаете это миллиарды раз, чего не происходит при разборе запросов. Вопросы размера и производительности, возможно, были значительными, когда эта часть Oracle была впервые разработана, но они не очень актуальны в наши дни.
Сара Г
-7

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

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

user173422
источник
29
Было бы неплохо иметь возможность присваивать имена внешним ключам именам таблиц и столбцов, к которым они присоединяются - поэтому, когда выдается исключение внешнего ключа, вам не нужно искать столбцы, вызвавшие сбой. С другой стороны, Oracle может просто рассказать вам эту информацию ...
Крис Гилл
10
Есть много причин, по которым нам нужно более 30 символов, хотя обычно 30 символов достаточно. Иногда имя таблицы должно быть достаточно многословным, чтобы иметь смысл. Например, у меня есть вызов этой таблицы sch_PatternRunTimeException, он ровно 30 символов. Теперь мне нужно добавить вызов таблицы зеркалирования sch_DevPatternRunTimeException. Этот дополнительный стандарт именования из 3 символов не работает для Oracle, у MSSQL нет проблем. Это заставляет меня придумать новое имя. Переименование таблицы выполнимо, но оно повлияет на операции наших клиентов, которых мы стараемся избегать.
DSUM
6
Если в 99,9% процентов возможных случаев раздражает +30 символов, это не значит, что они пригодятся другим 0,1%.
Рене Ниффенеггер
14
Аааа, аргумент о скользком склоне. Ограничение в 4 буквенно-цифровых символа позволило бы нам получить более 1 миллиона комбинаций таблиц, поэтому никому на самом деле не «нужно» больше 4. Но мы здесь. И это на самом деле не 30 символов, а менее 30 символов, так как мое соглашение об именах регистров в паскале должно быть устранено из-за отсутствия чувствительности к регистру и заменено именами с разделителями подчеркивания. Объедините это с различными префиксами / суффиксами, и вам повезет иметь даже 20 символов. Кто не предпочел бы надежное индексное имя, повторяемое с ошибкой нарушения из-за мешанины сокращений и подчеркиваний?
b_levitt
Договорились, что это не решение проблемы. Обычно людям не нужны более длинные имена столбцов, но во многих случаях имена объектов генерируются автоматически.
fool4jesus