Grenzen von MS-SQL/Oracle/MySQL bezüglich varchar-Felder

[Bernhard Geyer]

Beim MS-SQL-Server können in einem Datensatz maximal 8060 (!) Bytes in varchar-Felder gefüllt werden (Max Tablerow-Size).

Weiss jemand, ob es eine solche Beschränkung auch bei MySQL bzw. Oracle vorhanden ist bzw. wie dort die Grenzen sind?

[Sharky]

Zitat von Bernhard Geyer:

...ob es eine solche Beschränkung auch bei MySQL...

Hai Bernhard,
bei mySQL ist laut meiner Doku bei 255 schluss.

[-tobi-]

Hallo,

Oracle kann Felder als VarChar und VarChar2 für 4000 Zeichen anlegen.

Gruß
tobi

[Bernhard Geyer]

Danke für die Infos, aber ihr habt die Frage Falsch verstanden.

Es geht nicht darum wieviel ein varchar-Feld aufnehmen kann, sondern bis zu welcher Länge (Speicherumfang) alle varchar-Felder in einem Record gefüllt werden können.

Beispiel:
Ich definiere eine Tabelle mit 10 varchar-Feldern der Länge 1000. Diese kann ich jedoch nicht alle komplett füllen, da diese sonst 10000 Zeichen = 10000 Bytes benötigen würden. Und dies ist über der 8060 Bytes-Grenze des MS-SQL-Server.

[Sharky]

Zitat von Bernhard Geyer:

Danke für die Infos, aber ihr habt die Frage Falsch verstanden.....

Dann musst Du gaaaaanz deutlich schreiben
Ich habe noch nichts über eine Einschränkung bei mySQL gefunden. Ich werde es im zweifel einfach mal testen.

[Robert_G]

Zitat von -tobi-:

Hallo,

Oracle kann Felder als VarChar und VarChar2 für 4000 Zeichen anlegen.

Gruß
tobi

Generell würde ich in Ora nie den Typ VarChar verwenden. Dafür gibt's ja VarChar2, der ein paar Optimierungen hinter sich hat.

Zitat von Bernhard:

Beim MS-SQL-Server können in einem Datensatz maximal 8060 (!) Bytes in varchar-Felder

Man könnte also gerade mal 2 VarChar(2000) bzw. 1 VarChar(4000) in einer Tabelle haben??? (Ich weiß jetzt aber nicht, ob das VarChar im SQL Svr auch 2 Byte/Character hat)

OT: solche großen Textfelder gehören IMHO sowieso in einen CLob

[-tobi-]

Zitat von Robert_G:

Generell würde ich in Ora nie den Typ VarChar verwenden. Dafür gibt's ja VarChar2, der ein paar Optimierungen hinter sich hat.

Das habe ich schon gemerkt. Ich bin schon mit Char und mit Varchar in Fehler gelaufen.

[Bernhard Geyer]

Zitat von Robert_G:

Generell würde ich in Ora nie den Typ VarChar verwenden. Dafür gibt's ja VarChar2, der ein paar Optimierungen hinter sich hat.

Haben wir eh. varchar war als "Überbegriff" für alle Datenbanken gedacht.

Zitat von Robert_G:

(Ich weiß jetzt aber nicht, ob das VarChar im SQL Svr auch 2 Byte/Character hat)

Nur wenn es als nvarchar angelegt wurde. varchar hat 1 Byte/Character[/quote]

Zitat von Robert_G:

OT: solche großen Textfelder gehören IMHO sowieso in einen CLob

Ich habe nicht das Problem das das Feld so groß wird, sondern das ich viele kleine Felder habe (vom Kunden auch konfigurierbar). Und danach will er auch suchen. Und (bei MS-SQL) sind die ntext-Felder nicht sehr kooperativ bezüglich suche (Bei Memofelder geht nur der Abfrage nach null bzw. like).

[Robert_G]

Zitat:

Nur wenn es als nvarchar angelegt wurde. varchar hat 1 Byte/Character

Genau darauf würde ich mich nicht verlassen. Mir ist es oft genug untergekommen, dass für einen VarChar2 2 B/Chr verwendet wurden.

Wenn es im SQL Svr wirklich nur 1 B/Chr ist, kannst du dich bei 8KB doch ziemlich auslassen (solange es wirklich nur "kleinere" Felder sind).

OT: Diese Einschränkung ( die 8 KB) gehört wohl neben dem SELECT-Locking zu den nervigsten "Features" von M$ Spross...

[Bernhard Geyer]

Zitat von Robert_G:

Genau darauf würde ich mich nicht verlassen. Mir ist es oft genug untergekommen, dass für einen VarChar2 2 B/Chr verwendet wurden.

Bei MS-SQL sollte das aber nicht der Fall sein (evtl. bei anderen DB's). Auszug aus der MS-SQL-Hilfe

Zitat:

varchar[(n)]

Nicht-Unicode-Zeichendaten variabler Länge mit n Byte. n muss ein Wert zwischen 1 und 8.000 sein. Die Speichergröße entspricht der tatsächlichen Länge der eingegebenen Daten in Byte, nicht n Byte. Die eingegebenen Daten können 0 Zeichen lang sein. Die SQL-92-Synonyme für varchar sind char varying oder character varying.

Zitat von Robert_G:

Wenn es im SQL Svr wirklich nur 1 B/Chr ist, kannst du dich bei 8KB doch ziemlich auslassen (solange es wirklich nur "kleinere" Felder sind).

Muß jedoch dafür sorgen, das wenn der User die Konfiguration so wählt, das er evtl. über diese Grenze, das 'ne Warnmeldung erscheint.

Zitat von Robert_G:

OT: Diese Einschränkung ( die 8 KB) gehört wohl neben dem SELECT-Locking zu den nervigsten "Features" von M$ Spross...

Ich kenn noch eine: Tabelle mit Primärschlüssel(varchar), varcharfeldern und ntext-Feldern.
Und versuch mal in einer Update-Anweisung alle Felder gleichzeitig zu aktualisieren - Wird nicht gehen!

OT: Wenn man mehr mit den diversen DBMS zu tun hat, so wundert man sich nicht, das immer wieder neue DBMS entwickelt werden