Es kommt also vor, dass das Produkt, das wir entwickeln, mit mehreren relationalen Datenbanken funktioniert. Dies sind MS SQL, Postgres und Oracle. Es gab Starts unter vielen Dingen von MySQL bis zum Verstorbenen, wahrscheinlich Firebird und exotische Sybase mit DB2, aber das ist nicht die Geschichte.
Wenn mit MS SQL und Postgres alles mehr und weniger verständlich und vertraut ist, dann erleben wir mit Oracle jedes Mal einige Überraschungen. Ein kluger Leser wird sofort bemerken, dass "unsere Hände krumm sind" und wir "einfach nicht wissen, wie man es kocht", aber wenn der liebe Leser wissen möchte, wie sich Varchar (oder besser gesagt varchar2
) in gottähnlichem Orakel von seinen Brüdern unterscheidet, dann bitte unter Katze.
Wie alle modernen Systeme speichern wir Daten im Unicode-Format (derzeit UTF-8). Warum könnte dies für relationale Datenbanken wichtig sein?
Wenn Ihre Datenbank beispielsweise eine Mischung aus Unicode- und Nicht-Unicode-Datentypen enthält, können einige Treiber dies nicht. Beispielsweise kann der JTDS-JDBC-Treiber für MS SQL Server entweder im Unicode-Modus oder in Ansi arbeiten. Wenn Sie sich entscheiden, eine Nicht-Unicode-Spalte (varchar / char) zu "speichern" und zu erstellen, erhalten Sie dementsprechend eine Unicode-> ansi-Konvertierung auf der Ebene der Dateneinfügung in die Tabelle und erzielen höchstwahrscheinlich den gegenteiligen Effekt (zumindest eine Verlangsamung der Dateneinfügung, andernfalls) und auf der Suche).
Also die Geschichte. Unser Anwendungsserver überprüft die maximal zulässige Länge von Feldern, bevor sie eingefügt werden (hier muss festgelegt werden, dass die Überprüfung nicht gemäß den Datenbankdaten, sondern gemäß unseren internen Metadaten durchgeführt wird), aber trotzdem "fangen" wir manchmal unter Oracle einen Fehler wieORA-12899: value too large for column.
? , , Oracle.
. , varchar2
:)
, ,
alter table address modify street varchar2(150);
150 - ( -)? - :) .
alter table address modify street varchar2(150 char);
.. char
-byte
. ( ) - .
, UTF-8, , 4 ( 1 ANSI, 2 4 ).
Unicode !? , , , " ". .. , : legacy, , Unicode' " ", , backup 86 imp - .
? tool, , create table
char
:)
:
, , , .
SELECT value FROM NLSDATABASEPARAMETERS WHERE parameter='NLSLENGTHSEMANTICS';
, , " ":
SELECT TABLE_NAME, COLUMN_NAME, DATA_LENGTH, CHAR_USED
FROM USER_TAB_COLUMNS
WHERE DATA_TYPE = 'VARCHAR2' AND CHAR_USED = 'B'
ORDER BY TABLE_NAME, COLUMN_NAME
P.S. , , (, 100% ansi ), Unciode … ...
P.P.S. Regexp " " varchar2\(\s*\d+\s*\)
P.P.P.S. StackOverflow
PPPPS Hier ist, was Oracle über das Ändern des Parameterwerts NLSLENGTHSEMANTICS
in einen vernünftigeren Wert denkt. "Oracle empfiehlt dringend, den Parameter NLS LENGTH SEMANTICS in der Instanz- oder Serverparameterdatei NICHT auf CHAR zu setzen. Dies kann dazu führen, dass viele vorhandene Installationsskripte dies tun Erstellen Sie unerwartet Spalten mit Semantik der Zeichenlänge, was zu Laufzeitfehlern führt, einschließlich Pufferüberläufen. " https://docs.oracle.com/cd/E24693 01 / server.11203 / e24448 / initparams149.htm