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

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”.

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)

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.

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.

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.

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).

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.

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.

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.

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ść ...

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