Dlaczego nazwy tabel / kolumn / indeksów Oracle są ograniczone do 30 znaków?

149

Rozumiem, że wiele lat temu istniałyby tego rodzaju ograniczenia, ale obecnie z pewnością można by je łatwo zwiększyć. Mamy konwencje nazewnictwa obiektów, ale zawsze pojawia się przypadek, w którym osiągniemy ten limit - szczególnie w nazewnictwie kluczy obcych.

Czy ktoś naprawdę wie, dlaczego to nie jest większy rozmiar - czy jest większy w 11g?


Najwyraźniej odpowiedź jest taka, że ​​zepsuje obecnie skrypty, które nie są kodowane defensywnie. Muszę powiedzieć, że jest to bardzo niepokojąca sprawa, Oracle stara się być na bazę danych, z pewnością jest to jedna z tych rzeczy, które trzeba nieustannie poprawić, inaczej produkt umrze śmiercią tysiąca cięć.

Ilekroć widzę tego rodzaju sprzeciw na miejscu, myślę, że nadszedł czas, aby ugryźć kulę i rozwiązać problem. Jeśli ludzie uruchamiają skrypty, których nie sprawdzają ani nie obsługują podczas aktualizacji wersji Oracle, pozwól im ponieść konsekwencje tego wyboru. Podaj im flagę zgodności, zwiększając rozmiar do 4000, a następnie oszczędzaj mi straconego czasu podczas tworzenia obiektów polegającego na ciągłym liczeniu do 30, aby sprawdzić, czy nazwa jest „OK”.

Chris Gill
źródło
3
Skoro musi istnieć limit? Zrób to 64 znaki, a prawdopodobnie znajdziesz kogoś, kto zapyta, dlaczego nie jest to 128 itd. Jak długi jest kawałek łańcucha?
Przewodniczący
45
To prawda, ale 30 to bardzo krótki kawałek sznurka. Dlaczego nie może to być 4000 - rozmiar Varchar2 - czy Oracle naprawdę obchodzi, ile czasu upłynie po przeanalizowaniu zapytania?
Chris Gill
22
@TheChairman PostgreSQL ogranicza mnie do 63 znaków i nigdy nie miałem problemu z tym limitem długości. Jest na tyle duża, że ​​moje imiona będą pasować, a jeśli myślę o dłuższej nazwie, czas zacząć myśleć o negatywnym wpływie na czytelność. Z drugiej strony często napotykam na ograniczenia długości nazwy w Oracle i jestem zmuszony zmniejszyć czytelność mojego nazwiska z powodu limitu 30 znaków. Kilka osób może narzekać na limit 64 znaków , ale wiele osób ma już problemy z powodu limitu 30 znaków. Chodzi o spełnienie 99% przypadków użycia, a Oracle zawodzi tutaj.
jpmc26
1
Chodź, Oracle, zostałeś dinozaurem! Microsoft robi dobrą robotę, aby uczynić serwer SQL bardziej przyjaznym. Teraz rozluźnij ograniczenie długości nazwy.
user3454439
1
Przewiń do przodu do Oracle 12cR2, teraz jest 128 bajtów zamiast 30 :-) docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/ ...
Stefan L

Odpowiedzi:

71

Uważam, że to standard ANSI.

EDYTOWAĆ:

Właściwie myślę, że to standard SQL-92.

Wydaje się, że późniejsza wersja standardu opcjonalnie dopuszcza nazwy 128-znakowe, ale Oracle jeszcze tego nie obsługuje (lub ma częściowe wsparcie, o ile dopuszcza 30 znaków. Hmmm.)

Wyszukaj „F391, długie identyfikatory” na tej stronie ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Szukam ref)

cagcowboy
źródło
1
Hmm, nie tak czytałem ten dokument. Mówi mi, że F391 jest pozycją w specyfikacji SQL / Foundation (cokolwiek to jest) i że Oracle ma częściowe wsparcie dla tego, z limitem 30 znaków.
skaffman
21
Częściowa zgodność. Co za żart. „nasze śruby są częściowo zgodne ze standardami metrycznymi, z wyjątkiem tego, że nie są metryczne”.
Jens Schauder
5
Nie przeczytałem szczegółowo specyfikacji F391, ale zakładam (może niepoprawnie), że „Długie identyfikatory” oznaczają zwiększenie długości identyfikatorów z 30 do 128. Mówiąc, że „częściowo” obsługujesz to, zezwalając na 30 znaków, jest trochę bezczelny. Nie obsługujesz nowego standardu, nadal wspierasz stary standard (chociaż 25% drogi do nowego standardu) Czy to miało sens? !!?
cagcowboy
7
Standard SQL-92 jest tutaj contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt , ale jeśli przeczytasz sekcję "17.1 Opis obszarów deskryptorów pozycji SQL", mówi ona, że ​​identyfikatory takie jak nazwy i schematy muszą zezwalać na co najmniej 128 postacie.
Rick
46
Sam fakt, że fani Oracle nie widzą przydatności ponad 30 identyfikatorów znaków, jest niepokojący. „Nadaj imiona znaczenie / opis, używaj podkreśleń zamiast wielbłądów i nie przekraczaj 30 znaków”. To nigdy nie przekroczyłoby 30 znaków. Amirite? Raczej skracaj swoje skróty, a jeśli żadna z nazw nie ma sensu, poświęć cały dzień na czytanie / aktualizowanie dokumentacji.
Adam Jones,
45

Oprócz argumentu cagcowboya, który wywodzi się ze standardu SQL (historycznie podejrzewam, że decyzja Oracle doprowadziła do standardu SQL, ponieważ Oracle wyprzedziło standaryzację SQL), założyłbym się, że duża część niechęci do dopuszczania dłuższych identyfikatorów wynika z uświadomienie sobie, że istnieją miliony administratorów baz danych z milionami niestandardowych skryptów, z których wszystkie zakładają, że identyfikatory mają 30 znaków. Zezwalanie na każdą linię kodu, która wygląda jak

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

nagłe zerwanie, ponieważ DBA 15 lat temu użyło VARCHAR2 (30) zamiast DBA_TABLES.TABLE_NAME%TYPEw scenariuszu, spowodowałoby masowy bunt. Założę się, że sama Oracle ma tysiące miejsc, w których przez lata robiono tego typu rzeczy w różnych pakietach i komponentach. Modernizacja całego istniejącego kodu do obsługi dłuższych identyfikatorów byłaby ogromnym projektem, który prawie na pewno wygenerowałby znacznie więcej kosztów w czasie programisty, czasu kontroli jakości i nowo wprowadzonych błędach, niż przynosiłby korzyści.

Justin Cave
źródło
13
+1 Jest to prawie na pewno jedna z wielu wad starszej konstrukcji Oracle.
skaffman
43
Z pewnością nadszedł czas, aby rozwinąć parę i ją zwiększyć - dodaj flagę, aby administratorzy baz danych mogli ją zawęzić z powrotem do 30. Starsze problemy, takie jak ta, zawsze powinny być konfrontowane i sortowane, w przeciwnym razie skończy się to paraliżem całej bazy kodu, a ludzie po prostu się ruszą na coś innego
Chris Gill
6
Nie tylko miliony linii kodu napisanego przez DBA, ale bez wątpienia również mnóstwo wewnętrznego kodu Oracle. Ten temat pojawił się podczas sesji z Stevenem Feuersteinem i powiedział, że nie sądzi, aby kiedykolwiek go zmienili.
Matthew Watson
10
Nie mogliby też ogłosić tego jako nowej funkcji ... spędzali dużo czasu na zwiększaniu limitu, a następnie ogłaszali, że „możesz teraz używać nazw dłuższych niż 30 znaków!”. Byliby pośmiewiskiem.
skaffman
9
Jeśli nadal używasz 15-letnich skryptów, coś jest nie tak . Ponadto ich naprawienie byłoby jednorazowym kosztem (być może trochę więcej na dalsze utrzymanie), podczas gdy programiści będą nadal marnować czas na niepotrzebne tworzenie okropnie skróconych nazw w nieskończoność. @skaffman Są już pośmiewiskiem, jeśli nie można tego naprawić (i wiele innych decyzji projektowych, które są żałosne w erze współczesnej, jak brak typów logicznych lub autoinkrementujących), jeśli o mnie chodzi.
jpmc26
11

Szukałem tego i znalazłem to pytanie za pośrednictwem Google, ale dowiedziałem się również, że od Oracle 12c Release 2 (12.2) tak już nie jest. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

W pewnym momencie każdy DBA lub programista osiągnie punkt, w którym limit 30 znaków dla nazw obiektów spowodował problem. Ten limit może być bardzo bolesny podczas wykonywania projektów migracji z SQL Server lub MySQL do Oracle. W Oracle Database 12cR2 maksymalna długość większości identyfikatorów wynosi teraz 128 znaków.

Według ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ) jest to nowa funkcja w wersji 12.2 . Według tego posta 12.1 nadal było ograniczone do 30 znaków.


Edycja: Oto link do oficjalnej dokumentacji Oracle wyjaśniającej zmianę. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

Począwszy od Oracle Database 12c Release 2 (12.2), maksymalna długość nazw identyfikatorów dla większości typów obiektów bazy danych została zwiększona do 128 bajtów.

Kanmuri
źródło
128 bajtów / 4 bajty (Unicode) = 32 znaki. Przynajmniej rozumiem, że 4 bajty dla znaków innych niż Unicode, czy nie jest to rzadkie? Muszę się zastanawiać, czy to po prostu oznacza, że ​​teraz obsługują Unicode? Tak jak VARCHAR2(2)nie oznacza 2 znaków, ale 2 bajty.
Seth
1
Rozumiem, że masz rację, ale liczba znaków i bajtów zależy od zestawu znaków bazy danych. To ustawienie określa kodowanie typów danych char (takich jak varchar2), a także kodowanie identyfikatorów db. Kontrastuje to z zestawem znaków narodowych, który jest używany dla typów danych nchar. Więc tak, jeśli masz takie kodowanie, że twoje identyfikatory używają 4 bajtów na znak (zakładając, że może to być użyte jako zestaw znaków DB), miałbyś teraz 32 zamiast 7. Ale myślę, że w większości przypadków identyfikatory byłyby znaki jednobajtowe.
Kanmuri
6

Biorąc pod uwagę praktyczną potrzebę ograniczenia długości identyfikatorów, dobry projekt ogranicza długość rzeczywistych nazw, aby uniknąć uderzenia w sufit, gdy nazwy są łączone ze sobą oraz z przedrostkami i przyrostkami.

Na przykład konwencja nazewnictwa ograniczeń klucza obcego

FK_<table1>_<table2> 

ogranicza nazwy tabel do 13 znaków lub mniej; większość baz danych będzie potrzebować więcej przedrostków i przyrostków, co dodatkowo ogranicza długość nazw tabel.

Lorenzo Gatti
źródło
5

Naruszenia ograniczeń są zgłaszane w SQLERRM, który jest ograniczony do 255 znaków i którego większość klientów używa do wyświetlania błędów. Podejrzewam, że zwiększenie dopuszczalnego rozmiaru nazw ograniczeń znacząco wpłynęłoby na możliwość zgłaszania naruszeń (zwłaszcza w przypadku, gdy naruszenie ograniczenia zostało przepuszczone przez kilka warstw kodu PL / SQL).

Gary Myers
źródło
Więc poszerz ten stół?
skaffman
2
To nie jest tabela, ale sposób, w jaki oprogramowanie klienckie faktycznie otrzymuje błędy z bazy danych.
Gary Myers,
Długość @skaffman SQLERRM jest specyfikacją API / ABI. Zmiana tego oznaczałaby konieczność łatania wszystkich sterowników OCI na planecie (w przeciwnym razie przepełnienie bufora). Mogliby wprowadzić zmianę do klienta, aby najpierw zwiększyć buflen w OCI 13, a serwer w czymś takim jak Oracle 15, gdzie klienci OCI 10 nie byliby już, jak sądzę, obsługiwani. (Może nawet rozważają to teraz, ale główne wersje Oracle są wydawane tylko co kilka lat; a wtedy nadal możemy napotkać problemy z aktualizacją skryptów / aplikacji, gdy aplikacje zostaną przeniesione na inny serwer / klienta).
cowbert
4

Uważam, że 30-znakowy identyfikator pochodzi z języka COBOL, który został ustandaryzowany pod koniec lat pięćdziesiątych. Ponieważ programy w języku COBOL były głównym użytkownikiem SQL (a wcześniej SEQUEL (i wcześniej QUEL)), ta liczba musiała wydawać się rozsądna dla długości identyfikatora.

Michael Dillon
źródło
5
Wydaje mi się, że pierwsza wersja Oracle została napisana w języku Fortran, który moim zdaniem ma limit długości identyfikatora wynoszący 31. Może to ma znaczenie.
David Aldridge
4

Wszystkie te „ograniczenia” pozostają po odpowiedzi na ograniczenia narzucone przez architekturę procesorów z lat 70-tych. Od tego czasu procesory ewoluowały do ​​tego stopnia, że ​​ograniczenia te nie są już potrzebne; są po prostu pozostawione. Jednak ich zmiana to WIELKA sprawa dla twórców RDBMS. Ponieważ te ograniczenia długości wpływają na wszystko, co następuje w dalszej części, zmiana nie jest pożądana, aby dostosować, powiedzmy, że dłuższa nazwa procedury może i prawdopodobnie zepsuje wiele innych rzeczy, takich jak raportowanie wykonania, słownik danych itp., I tak dalej. Wymagałbym poważnego ponownego napisania Oracle RDBMS.

Prochowiec
źródło
2

Bezpośrednia odpowiedź na to pytanie jest taka, że ​​styl Oracle jest dziedziczony ze starszych pomysłów, w których 30 wydawało się dużo, a znacznie więcej zwiększyłoby ryzyko odpięcia pamięci podręcznej słownika od rzeczywistej pamięci w typowych bazach danych.

W przeciwieństwie do tego, przestrzeń nazw ODBC pochodzi z zupełnie innego miejsca, w którym zestawy danych są szybko wyodrębniane poprzez analizę tabeli w arkuszu Excel i automatyczne tworzenie tabel bazy danych z nazwami kolumn pobranymi z nagłówków tabel arkuszy. Takie myślenie prowadzi do dopuszczenia identyfikatorów, które zawierają nawet osadzone powroty karetki i oczywiście znaki specjalne i mieszane wielkości liter. To rozsądna abstrakcja, ponieważ modeluje sposób myślenia dzisiejszych analityków danych.

Nieważne, SQL92, zgodność z ODBC naprawdę ma znaczenie dla dzisiejszej uniwersalnej bazy danych, a inni dostawcy rozwiązali to lepiej niż Oracle. Na przykład nawet Teradata, który przez wielu nie jest postrzegany jako wszechobecny gracz, obsługuje DWIE przestrzenie nazw, z cudzysłowami i bez nich, pierwszy z limitem 30 znaków, drugi z pełną implementacją ODBC, w której obsługiwane są dziwne, długie identyfikatory .

Nawet na tradycyjnej arenie dużej bazy danych 30 znaków jest często problemem, gdzie nazwy mają pozostać znaczące, spójne i zapadające w pamięć. Gdy zaczniesz projektować wyspecjalizowane struktury z dziedziczeniem nazwanym rolami, zaczniesz skracać skróty, a spójność wkrótce umiera, ponieważ na przykład ten sam identyfikator główny renderowany jako nazwa tabeli lub nazwa kolumny będzie wymagał w jednym przypadku dalszego skrótu, aw innym nie. . Jeśli do takich warstw zapraszani są prawdziwi użytkownicy w znacznej liczbie, konsekwencją jest bardzo słaba użyteczność i na szczęście w przypadku starzejącej się bazy danych głównym motywem jest teraz oddzielenie użytkownika od bazy danych za pomocą warstw obiektów i narzędzi BI.

Pozostawia to warstwę bazy danych w gestii zespołów DBA i architektów danych, którym być może nie przeszkadza. Wydaje się, że opracowywanie schematów skrótów to nadal praca na całe życie.

To, że firma Oracle nie zajęła się tym starym ograniczeniem, prawdopodobnie odzwierciedla głównie fakt, że nie traci (jeszcze) wiele na rzecz konkurencji, gdy nie może bezpośrednio przenosić projektów baz danych zbudowanych przy użyciu dłuższych identyfikatorów.

atconsul
źródło
Nie do Oracle. ODBC to dziecko Microsoftu, a nie Java. Jest to nadal osobny lib pomocnik zlinkowana OCI (spojrzenie na sposób instantclient jest wdrażany - w celu uzyskania ODBC pracy z instantclient trzeba zarówno kierowcy OCI i ODBC instantclient zamki). Podstawową platformą kliencką Oracle (poza starszą wersją Pro * C / C / C ++) jest JDBC, która jest bezpośrednio połączona z OCI, a nie ODBC.
cowbert
1

Wszystkie powyższe komentarze są słuszne, ALE musisz pamiętać o kosztach wydajności dłuższych nazw. Na początku lat 90-tych, kiedy Informix ustawił ogromny billboard „Informix Faster Than Oracle!” na trasie 101 obok siedziby Oracle Informix dopuszczał nazwy tabel krótsze niż 18 znaków! Powód jest oczywisty - nazwy tabel w ich dosłownej formie (tj. Jako rzeczywiste nazwy, a nie „t138577321” lub coś podobnego) są przechowywane w Słowniku danych. Dłuższe nazwy oznaczają większy słownik danych, a ponieważ słownik danych jest czytany za każdym razem, gdy zapytanie wymaga twardej analizy, większy słownik danych oznacza słabą wydajność ...

Raphael
źródło
7
Nie ma absolutnie żadnego powodu, aby dokładne dopasowanie krótkich ciągów było wąskim gardłem w jakimkolwiek nowoczesnym oprogramowaniu, chyba że robisz to miliardy razy - co nie ma miejsca w przypadku analizowania zapytań. Rozważania na temat rozmiaru i wydajności mogły być istotne, gdy ta część Oracle była projektowana po raz pierwszy, ale obecnie nie są one tak naprawdę istotne.
Sarah G.
-7

ok, ograniczenie istnieje ....

ale czy naprawdę POTRZEBUJESZ więcej niż 30 znaków, aby nazwać tabelę / indeks / kolumnę?

podczas pisania zapytań, z tym ograniczeniem WCIĄŻ uważam, że niektóre nazwy kolumn / tabel są denerwujące. Gdyby limit był wyższy, mógłbym natknąć się na tabele wymagające zapytania, takiego jak:

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.

Przepraszam za wielkie słowa: P

user173422
źródło
29
Byłoby miło móc nazwać klucze obce nazwami zarówno tabel, jak i kolumn, do których dołączają - dlatego w przypadku wyrzucenia wyjątku klucza obcego nie trzeba szukać kolumn, które spowodowały błąd. Z drugiej strony Oracle może po prostu przekazać ci te informacje ...
Chris Gill,
10
Istnieje wiele powodów, dla których potrzebujemy więcej niż 30 znaków, chociaż zwykle wystarczy 30 znaków. Czasami nazwa tabeli musi być wystarczająco szczegółowa, aby mieć znaczenie. Na przykład mam to wywołanie tabeli sch_PatternRunTimeException, ma dokładnie 30 znaków. Teraz muszę dodać wywołanie tabeli dublowania sch_DevPatternRunTimeException. Ten dodatkowy standard nazewnictwa 3 znaków nie działa dla Oracle, MSSQL nie ma problemu. To zmusza mnie do wymyślenia nowej nazwy. Zmiana nazwy tabeli jest wykonalna, ale wpłynie to na działalność naszych klientów, czego staramy się unikać.
dsum,
6
Jeśli w 99,9% możliwych przypadków +30 znaków jest irytujących , nie oznacza to, że przydałyby się pozostałe 0,1%.
René Nyffenegger
14
Ahhh, argument o śliskim zboczu. Limit tylko 4 znaków alfanumerycznych dałby nam ponad milion kombinacji tabel, więc nikt tak naprawdę nie potrzebuje więcej niż 4. A jednak jesteśmy tutaj. I to nie jest tak naprawdę 30 znaków, to mniej niż 30 znaków, ponieważ moja konwencja nazewnictwa wielkości liter w pascalu musi zostać porzucona z brakiem rozróżniania wielkości liter i zastąpiona nazwami rozdzielanymi podkreśleniem. Połącz to z różnymi prefiksami / sufiksami i masz szczęście, że masz nawet 20 znaków. Któż nie wolałby, aby solidna nazwa indeksu odbijała się echem z błędem naruszenia zamiast mieszanki skrótów i podkreśleń?
b_levitt,
Uzgodniono, że to nie rozwiązuje problemu. Zwykle ludzie nie potrzebują dłuższych nazw kolumn, ale istnieje wiele przypadków, w których nazwy obiektów są generowane automatycznie.
fool4jesus