hi Leutz,

Ich hätte wiedermal eine kniffelige Frage:

In meiner Datenbank befinden sich ca 3000 "Char-Felder", von denen im Normalfall nur ca 2000 gefüllt werden, da der Kunde die Funktion, welche diese Felder benötigt nicht nutzt (benutzen darf, da er sie nicht gekauft hat) Jene benötigen somit immer den Speicherplatz des Char-Feldes (z.B.: 80 Byte) obwohl das Feld <null> ist.
Wenn ich mir dann die Vorgangspositionen dazu anschaue, wären das
ca 1.000.000 x 80 Byte = 76 MB um welche die DB kleiner werden würde.
(Komprimierung ausgeschlossen)

Mir ist jedoch auch bekannt, das VarChar einen größeren Zeitaufwand beim Speichern und Anzeigen von Datensätzen benötigt. Ist dieser Zeitaufwand minimal, oder zieht sich das bei Auswertungen "in die Länge"??

Würdet ihr mir dazu raten, und wenn ja, wie realisier ich das??

Ich denke mal, zur Realisierung benötige ich dann einen SQL-Code mit 'RDB$Field_Typ ...'
(zu MrSpock zwinker)

Hoffe mal, dass eine große Diskussion hier aufkommt

mfg

OlliW

Hallo Olli,

die Zugriffszeiten habe ich nicht gemessen, aber bei den Datenmengen von denen du sprichst, dürfte diese Unterschied im Rauschen untergehen. Bei dieser Änderung brauchst du die Domain nicht zu ändern (obwohl das auch ginge), sondern du kannst das direct über SQL DDL machen:



oder, um die Änderung beim nächsten Mal zu vereinfachen:



und dann:

MrSpock hat folgendes geschrieben:

markieren Quelltext     1: alter table <tab1> alter <thevarfield> type varchar(10)

Das Würde bedeuten, ich müsste jedes Einzelne Feld anpacken, richtig?

Mein Updatescript ist sowieso schon über 5000 Zeilen ! Ohne Stored Procedures ! Die blanke Tipperei zum Ändern der Felder ist ganz schön Nerf-Tötend.

geht das nicht irgendwie mit RDB$Fied_Typ ..... damit ich das über die gesamt DB laufen lassen kann???

mfg

OlliW

ps: Ist der Geschwindigkeitsverlust wirklich so minimal??? Damals in der Schulzeit haben sie immer darauf getrimmt, varchar nur im Notfall zu benutzen, wegen der Geschwinigkeit!

haha !

hab die Lösung, wie es schneller funzt

- Erstellen 2 neuer Datenbanken
- Jeweils 1 Tabelle
- Jeweils 3 Felder (DB1 mit 3x Char und DB2 mit 3x Varchar)
- Databasecomparer sagt:


Daraus macht man kurzer Hand:



und schon funzt alles

Ich stopp mal die Zeit nachdem ich unsere Demodatenbank durch die Mangel genommen habe, hehe

mfg

OlliW

EDIT:
zefix, Zu früh gefreut funktioniert doch nicht alles:

Fehlermeldung: Ungültiger Felddeskriptor

sagt das jemanden was?? Im Prinzip müsste sich doch nichts geändert haben, außer die Variable Länge des DB-Feldes!

Hallo Olli,

wenn sich die Sortierreihenfolge und die Länge nicht ändern, könntest du ALLE Char in "gleichgroße" VARCHAR Felder umwandeln mit:



Mach aber zur Sicherheit vorher eine Datensicherung! (Wie immer beim Manipulieren von Systemtabellen)

[edit]ooops, da warst du ja schneller als ich[/edit]

hehe, ätsch

hast noch nen Tipp für mich???

Hallo Olli,

wann kommt denn der Fehler mit dem Felddescriptor? Kannst du die Tabelle identifizieren, die den Fehler erzeugt? Dann wäre es interessant die genaue Felddefinition vor der "Umwandlung" anzuschauen. Außer dem Typ sind eigentlich nur noch der Zeichensatz, die Sortierung und die Feldlänge bei CHAR / VARCHAR wichtig. Das sind demnach Kandidaten für die Fehlerursache.

Fehler Localisiert:

Im Programm wird eine TTable mit 3 Feldern geöffnet. (nr,bez,name)
- Nr = Integer;
- Bez = String;
- name= string;

Zeichensatz und Sortierreihenfolge sind nach dem Update identisch! Hat sich nichts geändert!


Beim Öffnen der Datenmenge (TableX.open) bringt er anschließend den Fehler.

tja, eigentlich dürfe das nichts ausmachen! Es sind weder Berechnungen noch Events im Table. Parameter zum Öffnen gibt es auch keine ! Nr ist Primärschlüssel!

Mehr gibts nicht.

hm... hängt es vielleicht an den Eigenschaften im Objektinspector???
Für Feld Bez und Name ist die DisplayWith 80, ebenso die Size.
Kann das hiermit zusammenhängen????

Will im Programm eigenltich nichts ändern. "Never Chance a running System!" Wie es so schön heisst.

Hallo Olli,

ja, das könnte mit dem OI zusammenhängen. Besser gesagt mit den persistenten Feldern im DataSet Objekt. Es wäre sinnvoll an den Stellen, die Probleme machen, das Feld über den Feldeditor zu löschen und wieder einzufügen. Achte aber darauf, ob du dem Feld schon Code oder Darstellungsinformationen zugewiesen hast.

jo,

ich verfolge die Sache mal weiter. Aber jetzt is erst mal Feierabend für heut

morgen folgt weiteres

mfg

OlliW