Почему имена таблиц / столбцов / индексов Oracle ограничены 30 символами?
Существуют конкретные способы реализации этого поставщика, поэтому было бы хорошо знать, какую базу данных вы используете. Я знаю решения для PostgreSQL и H2. Я реализовал эту функцию в базе данных H2, так что это то, что я знаю лучше всего:
H2 Database
PreparedStatement prep = conn.prepareStatement(
"select * from users where login in (select * from table(x int = ?))");
prep.setObject(1, new Object[] { "1", "2" });
ResultSet rs = prep.executeQuery();
PostgreSQL
WHERE login = ANY(?)
Затем установите параметр к массиву значений с использованием PreparedStatement.setArray (..) (not setObject как для H2).
5 ответов
Я считаю, что это стандарт ANSI.
РЕДАКТИРОВАТЬ:
На самом деле, я думаю, что это стандарт SQL-92.
Более поздняя версия стандарта, по-видимому, факультативно допускает 128-символьные имена, но Oracle еще не поддерживает это (или частично поддерживает его , поскольку он допускает 30 символов. Хммм.)
Найдите "F391, Длинные идентификаторы" на этой странице ... http: // stanford.
В дополнение к cagcowboy's То, что он происходит от стандарта 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 есть тысячи мест, где подобные вещи делались годами в различных пакетах и компонентах. Модернизация всего этого существующего кода для поддержки более длинных идентификаторов была бы грандиозным проектом, который почти наверняка принесет куда больше затрат времени разработчика, времени контроля качества и новых ошибок, чем принесет выгоду.
Нарушения ограничений сообщаются в SQLERRM, который ограничен 255 символами и который большинство клиентов используют, чтобы сделать ошибки видимыми. Я подозреваю, что увеличение допустимого размера имен ограничений значительно повлияет на способность сообщать о нарушениях (особенно там, где нарушение ограничения было обнаружено через несколько уровней кода PL / SQL).
хорошо, ограничение существует ....
но вам действительно НУЖНО больше, чем просто 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
Я считаю, что длина идентификатора в 30 символов взята из COBOL, который был стандартизирован в конце 1950-х годов. Поскольку программы COBOL были основным пользователем SQL (и SEQUEL до этого (и QUEL до этого)), это должно было казаться разумным числом для длины идентификатора.