Warum sind Oracle-Tabellen- / Spalten- / Indexnamen auf 30 Zeichen beschränkt?

Ich kann verstehen, dass es vor vielen Jahren diese Art von Einschränkung geben würde, aber heutzutage könnte diese Grenze sicherlich leicht erhöht werden. Wir haben Namenskonventionen für Objekte, aber es gibt immer einen Fall, in dem wir diese Grenze erreichen - insbesondere beim Benennen von Fremdschlüsseln.

Weiß jemand wirklich, warum dies keine größere Größe ist - oder ist es in 11 g größer?

Anscheinend ist die Antwort, dass es aktuelle Skripte kaputt macht, die nicht defensiv codiert sind. Ich sage, das ist eine sehr besorgniserregende Sache. Oracle versucht, die Datenbank zu sein. Dies ist sicherlich die Art von Dingen, die Sie ständig verbessern müssen, sonst stirbt Ihr Produkt nach tausend Schnitten.

Immer wenn ich diese Art von Einspruch im Haus sehe, denke ich, ist es Zeit, die Kugel zu beißen und sie zu klären. Wenn Benutzer Skripts ausführen, die sie beim Upgrade von Oracle-Versionen nicht überprüfen oder warten, lassen Sie sie unter den Folgen dieser Auswahl leiden. Geben Sie ihnen ein Kompatibilitätsflag mit einer Größe von bis zu 4000 und sparen Sie mir dann die verschwendete Zeit, wenn ich Objekte erstelle, die ständig bis 30 zählen müssen, um zu überprüfen, ob der Name "OK" ist.

Ich glaube, es ist der ANSI-Standard.

BEARBEITEN:

Eigentlich denke ich, dass es der SQL-92-Standard ist.

Eine spätere Version des Standards scheint optional 128 Zeichennamen zuzulassen, aber Oracle unterstützt dies noch nicht (oder unterstützt dies teilweise, sofern 30 Zeichen zulässig sind. Hmmm.)

Suchen Sie auf dieser Seite nach "F391, Long Identifiers" ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Auf der Suche nach einem Schiedsrichter)

Zusätzlich zu Cagcowboys Argument, dass es vom SQL-Standard abgeleitet ist (historisch gesehen vermute ich, dass die Entscheidung von Oracle zum SQL-Standard führte, da Oracle vor der Standardisierung von SQL existierte), würde ich wetten, dass ein großer Teil der Zurückhaltung, längere Bezeichner zuzulassen, von dort herrührt die Erkenntnis, dass es Millionen von Datenbankadministratoren mit Millionen von benutzerdefinierten Skripten gibt, die alle davon ausgehen, dass Bezeichner 30 Zeichen lang sind. Erlaubt jede Codezeile, die so etwas wie geht

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

plötzlich zu brechen, weil der DBA vor 15 Jahren VARCHAR2 (30) anstelle DBA_TABLES.TABLE_NAME%TYPEdes Skripts verwendete, würde einen massiven Aufstand auslösen. Ich würde wetten, dass Oracle allein Tausende von Orten hat, an denen solche Dinge im Laufe der Jahre in verschiedenen Paketen und Komponenten durchgeführt wurden. Nachrüsten alle , dass Code bestehende mehr Kennungen zu unterstützen wäre ein enormes Projekt, das mit ziemlicher Sicherheit erzeugen würde Art und Weise mehr Kosten in Entwicklungszeit, QA Zeit, und neu eingeführte Fehler , als es Nutzen erzielen würde.

Ich habe dies nachgeschlagen und diese Frage über Google gefunden, aber auch herausgefunden, dass dies ab Oracle 12c Release 2 (12.2) nicht mehr unbedingt der Fall ist. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

Irgendwann hat jeder DBA oder Entwickler einen Punkt erreicht, an dem die Beschränkung auf 30 Zeichen für Objektnamen ein Problem verursacht hat. Diese Begrenzung kann bei Migrationsprojekten von SQL Server oder MySQL zu Oracle äußerst schmerzhaft sein. In Oracle Database 12cR2 beträgt die maximale Länge der meisten Bezeichner jetzt 128 Zeichen.

Dies ist laut ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ) eine neue Funktion in 12.2 . Laut diesem Beitrag war 12.1 immer noch auf 30 Zeichen beschränkt.

Bearbeiten: Hier ist ein Link zur offiziellen Oracle-Dokumentation, in der die Änderung erläutert wird. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

Ab Oracle Database 12c Release 2 (12.2) wurde die maximale Länge der Bezeichnernamen für die meisten Arten von Datenbankobjekten auf 128 Byte erhöht.

Angesichts der praktischen Notwendigkeit von Längenbeschränkungen für Bezeichner beschränkt ein gutes Design die Länge der tatsächlichen Namen, um zu vermeiden, dass die Obergrenze erreicht wird, wenn die Namen miteinander und mit Präfixen und Suffixen kombiniert werden.

Zum Beispiel eine Konvention zum Benennen von Fremdschlüsseleinschränkungen

FK_<table1>_<table2> 

begrenzt Tabellennamen auf 13 Zeichen oder weniger; Die meisten Datenbanken benötigen mehr Präfixe und Suffixe, wodurch die Länge der Tabellennamen weiter eingeschränkt wird.

Verstöße gegen Einschränkungen werden in SQLERRM gemeldet, das auf 255 Zeichen begrenzt ist und von den meisten Clients verwendet wird, um Fehler sichtbar zu machen. Ich vermute, dass eine Erhöhung der zulässigen Größe von Einschränkungsnamen die Fähigkeit zur Meldung von Verstößen erheblich beeinträchtigen würde (insbesondere, wenn eine Einschränkungsverletzung durch einige Ebenen von PL / SQL-Code gesprudelt wurde).

Ich glaube, dass die Länge von 30 Zeichen von COBOL stammt, das Ende der 1950er Jahre standardisiert wurde. Da COBOL-Programme der Hauptbenutzer von SQL waren (und SEQUEL davor (und QUEL davor)), muss dies eine vernünftige Zahl für die Bezeichnerlänge gewesen sein.

All diese "Einschränkungen" bleiben den Reaktionen auf Einschränkungen überlassen, die durch Prozessorarchitekturen aus den 70er Jahren auferlegt wurden. Seitdem haben sich Prozessoren so weit entwickelt, dass diese Einschränkungen nicht mehr erforderlich sind. sie sind nur übrig geblieben. Ihre Änderung ist jedoch für die Verfasser des RDBMS ein GROSSES Geschäft. Da diese Längenbeschränkungen alles beeinflussen, was sich stromabwärts ändert, ist es wohl oder übel, wenn man sagt, dass ein längerer Prozedurname viele andere Dinge wie Ausnahmeberichte, das Datenwörterbuch usw. usw. beschädigen kann und wird. Ich würde ein umfangreiches Umschreiben des Oracle RDBMS erfordern.

Die direkte Antwort auf die Frage lautet, dass der Oracle-Stil von älteren Ideen geerbt wurde, bei denen 30 viel zu sein schien, und viel mehr das Risiko erhöht hätte, den Wörterbuch-Cache in typischen Datenbanken aus dem realen Speicher zu entfernen.

Im Gegensatz dazu stammt der ODBC-Namespace von einem ganz anderen Ort, an dem Datensätze schnell extrahiert werden, indem eine Tabelle in einer Excel-Tabelle analysiert und automatisch Datenbanktabellen mit Spaltennamen aus Blatttabellenüberschriften erstellt werden. Wenn Sie so denken, können Sie Bezeichner zulassen, die sogar eingebettete Zeilenumbrüche enthalten, und natürlich Sonderzeichen und Groß- und Kleinschreibung. Es ist eine vernünftige Abstraktion, weil sie das Denken heutiger Datenanalysten modelliert.

Egal, SQL92, es ist die ODBC-Konformität, die für die heutige universelle Datenbank wirklich wichtig ist, und andere Anbieter haben dies besser angegangen als Oracle. Sogar Teradata zum Beispiel, das von vielen nicht als allgegenwärtiger Spieler angesehen wird, bietet ZWEI Namespaces mit und ohne Anführungszeichen, ersteres mit einem Limit von 30 Zeichen, letzteres eine vollständige ODBC-Implementierung, bei der seltsame lange Bezeichner berücksichtigt werden .

Selbst in der traditionellen Arena mit großen Datenbanken sind 30 Zeichen oft ein Problem, bei dem Namen aussagekräftig, konsistent und einprägsam bleiben sollen. Sobald Sie anfangen, spezialisierte Strukturen mit Verben mit Rollennamen zu entwerfen, beginnen Sie mit der Abkürzung von Abkürzungen, und die Konsistenz stirbt bald, da beispielsweise dieselbe Stammkennung, die als Tabellenname oder Spaltenname gerendert wird, in einem Fall eine weitere Abkürzung benötigt und in dem anderen nicht . Wenn echte Benutzer in erheblicher Anzahl zu solchen Ebenen eingeladen werden, sind die Folgen eine sehr schlechte Benutzerfreundlichkeit. Glücklicherweise besteht das Hauptantrieb für eine alternde Datenbank darin, Benutzer über Objektebenen und BI-Tools von der Datenbank zu trennen.

Dies überlässt die Datenbankschicht dem DBA und den Datenarchitektenteams, die vielleicht nicht so gestört sind. Die Ausarbeitung von Abkürzungsschemata scheint immer noch eine Aufgabe fürs Leben zu sein.

Dass Oracle diese alte Einschränkung nicht angesprochen hat, spiegelt möglicherweise hauptsächlich die Tatsache wider, dass es (noch) nicht viel Geschäft an seine Konkurrenz verliert, wenn es Datenbankdesigns, die mit längeren Bezeichnern erstellt wurden, nicht direkt portieren kann.

Alle obigen Kommentare sind richtig, ABER Sie müssen die Leistungskosten längerer Namen berücksichtigen. In den frühen 90er Jahren, als Informix eine riesige Werbetafel "Informix schneller als Oracle!" Auf der Route 101 neben dem Oracle-Hauptsitz erlaubte Informix Tabellennamen, die nur kürzer als 18 Zeichen waren! Der Grund liegt auf der Hand: Tabellennamen in ihrer wörtlichen Form (dh als tatsächliche Namen anstelle von 't138577321' oder so ähnlich) werden im Datenwörterbuch gespeichert. Längere Namen entsprechen einem größeren Datenwörterbuch. Da das Datenwörterbuch jedes Mal gelesen wird, wenn eine Abfrage eine harte Analyse erfordert, bedeutet ein größeres Datenwörterbuch eine schlechte Leistung ...

ok, die Einschränkung besteht ....

Aber BRAUCHEN Sie wirklich mehr als 30 Zeichen, um eine Tabelle / einen Index / eine Spalte zu benennen?

Wenn ich Abfragen schreibe, finde ich mit dieser Einschränkung immer noch einige Spalten- / Tabellennamen ärgerlich. Wenn das Limit höher wäre, könnte ich auf Tabellen stoßen, die eine Abfrage erfordern wie:

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.

Ich entschuldige mich für die großen Worte: P.