Чому назви таблиць / стовпців / індексів Oracle обмежені 30 символами?

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

Хтось насправді знає, чому це не більший розмір - чи він більший у 11 г?

Очевидно, відповідь полягає в тому, що він порушить поточні сценарії, які не кодуються захисно. Я кажу , що це дуже тривожна річ, 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), я б загрожував, що велика частина небажання дозволяти довші ідентифікатори походить від усвідомлення того, що є мільйони DBA з мільйонами користувацьких сценаріїв, за якими всі вважають, що ідентифікатори мають довжину 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 випуску 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 символами.

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

Починаючи з бази даних Oracle 12c, випуск 2 (12.2), максимальна довжина імен ідентифікаторів для більшості типів об’єктів бази даних збільшена до 128 байт.

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

Наприклад, угода про іменування обмежень іноземних ключів

FK_<table1>_<table2> 

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

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

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

Усі ці «обмеження» залишаються у відповіді на обмеження, накладені архітектурами процесорів, які звучать з 70-х років. З цього часу процесори еволюціонували до того, що ці обмеження більше не потрібні; вони просто залишилися. Однак їх зміна - велика угода для письменників RDBMS. Оскільки ці обмеження довжини впливають на все, що змінюється внизу, змінюючи його, мимоволі підходить, скажімо, довша назва процедури може і, ймовірно, порушить багато інших речей, таких як звітування про виконання, словник даних тощо, тощо, і так далі. Я зажадаю серйозного переписування Oracle RDBMS.

Пряма відповідь на питання полягає в тому, що стиль 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