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:

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:

Zitat von Bernhard Geyer

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

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

[Robert_G]

Zitat:

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:

Zitat von Bernhard

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

:wiejetzt: 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:

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:

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:

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:

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:

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:

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:

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! :roll:

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

[Robert_G]

Warum legst du nicht einfach für diese zig Varchars eine nested table an?
Falls es beim SQL Svr auch möglich ist nur die Referenz darauf in die Tabelle zu speichern dürfte die Tabelle im Endeffekt sogar massiv schneller werden. ;)

Aber frag's Pferd, wie du im SQL Svr nested Tables verwendest (ich bin nur ein Oracle- und werdender Caché -Entwickler :roll: )

[trifid]

kannst du die Tabelle denormailsieren ?
Tabelle ALT = key feld1 feld2 feld3 feldN
in
Tabelle NEU = key Zusammengehörigkeit FeldName feld

aus
ALT = 1 abc def ghi
wird
NEU = 1 1 Feld1 abc
2 1 Feld2 def
3 1 Feld3 ghi
31 2 Feld1 xyz
33 2 Feld2 xyz
34 2 Feld3 asd

Nachteil aufwendiger Zugriffsmechanis und leider auch Performance
die Query's für Felder sind aufwendiger
aber dadurch hast du auch eine dynamischeres Abbild deiner Strukturen (evtl. zukünftige Erweiterungen)

P.S. schön wäre, wenn man eine einfache HTML-Tabellen-Funktion für die Formartierung hätte

[Bernhard Geyer]

Zitat:

Zitat von Robert_G

Warum legst du nicht einfach für diese zig Varchars eine nested table an?
Falls es beim SQL Svr auch möglich ist nur die Referenz darauf in die Tabelle zu speichern dürfte die Tabelle im Endeffekt sogar massiv schneller werden. ;)

1, Es gibt AFAIK keine Nested-Tables bei MS-SQL-Server
2, Das Programm soll auch für MySQL und 'ner lokalen DB lauffähig sein. Und damit fallen solche spezialkonstrukte raus

Zitat:

Zitat von Robert_G

kannst du die Tabelle denormailsieren ?
Nachteil aufwendiger Zugriffsmechanis und leider auch Performance
die Query's für Felder sind aufwendiger

Wie Du schon sagst Aufwand + Performance. Die Tabelle hat bis zu 5 Mio. Datensätze.