Eintrag wird mit Leerzeichen aufgefüllt
Frank Basbeck
- datenbank
0 Frank Basbeck0 Tom0 Frank (no reg)
Hallo!
Ich fügen einen Datensatz über eine "Stored Procedure" in meine MSSql - Datenbank ein. Eine Spalte hat den Datentyp char(50). Beim Einfügen tritt nun der unerwünschte Effekt auf, dass der zur Verfügung gestellte (allokierte?) Platz für diese Spalte auch immer ausgenutzt, d.h. ggf. mit Leerzeichen aufgefüllt, wird.
Weiss jemand Rat?
[...]
Weiss jemand Rat?
Hab schon selber RTRIM(@Parameter) in der PSM
Peinliche Grüße!
Frank
Hello,
Ich fügen einen Datensatz über eine "Stored Procedure" in meine MSSql - Datenbank ein. Eine Spalte hat den Datentyp char(50). Beim Einfügen tritt nun der unerwünschte Effekt auf, dass der zur Verfügung gestellte (allokierte?) Platz für diese Spalte auch immer ausgenutzt, d.h. ggf. mit Leerzeichen aufgefüllt, wird.
Weiss jemand Rat?
Nimm eine andere Datenbank ;-)
Bei MySQL habe ich das Verhalten gerade am Montag erst überprüft, weil Andere der meinung waren, dass MySQL immer feste Satzlänge schreiben würde. Dem ist nicht so. Da steuert ein Feld vom Typ VarChar das Verhalten so, dass ebi Vorhandensein ALLE Textfelder variable Länge bekommen und damit der Datensatz auch.
Wie das in mssyql innen drin aussieht, weiß ich nicht. Ich hebe keines installiert.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Servus!
Nimm eine andere Datenbank ;-)
Ich würde MySQL mag ja ganz gut für Web-Anwendungen sein, aber sonst... *duck* (1)
Bei MySQL habe ich das Verhalten gerade am Montag erst überprüft, [...]
Diese Diskussion habe ich verfolgt, leider gab es keine Reaktion auf deinen Speicherdump (heisst das so?)
Wie das in mssyql innen drin aussieht, weiß ich nicht. Ich hebe keines installiert.
Also wie es "innen drin" aussieht, dass weiss wohl nur der liebe Gott und ehrlich gesagt möchte ich das auch bei gar keinem Ms-Produkt so ganz genau wissen ;-P
1 (Das soll keine Aufforderung zur Grundsatzdiskussion sein)
Hello,
Bei MySQL habe ich das Verhalten gerade am Montag erst überprüft, [...]
Diese Diskussion habe ich verfolgt, leider gab es keine Reaktion auf deinen Speicherdump (heisst das so?)
Ich denke, ja. Wenn man mit den Fakten kommt, wird die Luft meist dünn. Allerdings werde ich auch oft ertappt dabei, dass meine Vorstellung, wie es denn sein könnte oder müsste, nicht mit der Wirklichkeit übereinstimmt. Oft sind die Meinungsunterschiede abe auch nur Philosopie...
Die Sache mit den Satzarten und den Verweisen innerhalb des Speicherformats von MySQL hat mich doch noch eine Weile beschäftigt. Ich konnte aber bisher keine Beschreibung finden, was da wann warum passiert. Vielleicht muss man sich dann den Quellcode beschaffen. Liegt der eigentlich noch offen?
Wo lag denn jetzt eigentlich Dein Problem mit mssql? Stört Dich, dass zuviel Speicherplatz verschwendet wird, oder stört dich die Darstellung der Daten nach dem Holen aus der Tabelle?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
servus
Die Sache mit den Satzarten und den Verweisen innerhalb des Speicherformats von MySQL hat mich doch noch eine Weile beschäftigt. Ich konnte aber bisher keine Beschreibung finden, was da wann warum passiert. Vielleicht muss man sich dann den Quellcode beschaffen. Liegt der eigentlich noch offen?
http://downloads.mysql.com/snapshots.php
Wo lag denn jetzt eigentlich Dein Problem mit mssql? Stört Dich, dass zuviel Speicherplatz verschwendet wird, oder stört dich die Darstellung der Daten nach dem Holen aus der Tabelle?
Hauptsächlich bei der Darstellung, da ich nicht an jeder Stelle die anhängenden Leerzeichen entfernen möchte. Wie es mit dem Speicherplatz aussieht weiss ich ja nicht. Vermutlich werden für char(50) immer 50Byte belegt, ob ich nun null, 1, 2 oder 50 Zeichen schreibe, von daher kümmert mich der Platz nicht wirklich.
Hi,
wie es innen drin aussieht? Also wie SQL Server Daten physikalisch speichert?
-> in Pages à 8192 byte (wobei davon nur 8096 Byte übrigbleiben
aufgrund von Headerdaten)
-> ein Datensatz kann also maximal 8096 Byte umfassen, da Datensätze
nicht über mehrere Pages verteilt werden können
-> es werden zuerst die Daten aus Spalten fixer Datentypen (also auch char(50)) abgelegt bevor am Ende die variablen typen (varchar, varbinary etc) angeschlossen werden.
-> da in den Headerinformationen eines Datensatzes natürlich auch enthalten sein muss, welche spalte wann beginnt, ist es auch nur logisch, das wirklich die 50 byte reserviert werden, weil SQL Server dann [char] ja wie [varchar] behandeln müsste ...
Ich würde nicht von dem Auffüllen einer [char]-Spalte mit Leerzeichen als einem "unerwünschten Effekt" ausgehen. Der SQL Server Datentyp [char] ist nunmal nicht für die Verwendung variabel langer Zeichenfolgen konzipiert, dafür gibt es schließlich [varchar], was du in deinem Fall auch nehmen solltest.
Wenn eine Datenbanksoftware Datentypen wie [char] und [varchar] trennt (analog zu [binary] und [varbinary]) und dann aber in der Verwendung das typische des einen Datentyps auf den anderen anwendet, wozu macht sie dann die Unterscheidung erst ?
HTH, Ciao, Frank