Hi,

es geht um die Datentypen mit Interbase usw.:

BOOLEANGibts ja nicht. Aber was ist besser? Smallint oder CHAR (1) ? Gleiches gilt für Aufzählungstypen. Warum, weshalb etc.

REAL Tja, numeric, Decimal, Double Precision oder was?

STRINGder Unterschied zwischen VarChar und Char ist mir nicht ganz klar.

Ich habe hier z.B. 150 Bool-Felder. Und bevor ich die loslasse will ich wissen, was Sache ist. Wer weiß mehr?

Hi Hansa,

für den Boolean habe ich mir nen Typ gebastel:


In den meisten DB-Komponenten auf die es ankommt, kannst Du die Werte für True/False ja einstellen (z.B. DBCheckBox). Ein J bzw. N ist zudem für mich als Mensch immer noch leichter und unmissverständlicher zu lesen als ein 0 und 1.

Real/Double Precision würde ich wenn es geht vermeiden, bei Währungsangaben sowieso. Lieber ein Numeric/Decimal verwenden. Die haben einen Wertebereich der eigentlich alles abdecken sollte und zudem beliebig einstellbare Nachkommastellen.

Zwischen VarChar und Char gibts (fast) keinen Unterschied: Beide werden in der Datenbank gepackt gespeichert und beide werden bei der Übergabe an den Client in der vollen Länge übertragen. Der Unterschied liegt in der Darstellung: Bei Char werden die aufgefüllten leerzeichen auch angezeigt, bei VarChar eben nicht.

Grüße
Lemmy

wenn ich das so lese, glaube ich fast, nichts an der DB verändern zu müssen. Außer Lemmy scheint sich sowieso keiner Gedanken über solch elementare Sachen zu machen. Ich lasse jetzt CHAR so wie es ist und schau mir die verfügbaren IB-Beispiele an, ob ich jetzt CHAR (1) nehme oder SMALLINT. Falls jemand an dem Projekt mitmacht, will ich nicht für Unklarheiten / Umgewöhnung sorgen. Delphi-seitig läuft das eher darauf hin, ob öfters StrToInt oder IntToStr bemüht werden muß.

Allerdings ist noch eine Frage offen, die habe ich vergessen: ich benutze IBexpert, der gibt bei DECIMAL vor : (15,2). Macht es Sinn, das von Hand zu verändern? 15 Stellen sind wohl etwas viel. Ich vermute aber, daß auch das sich nur auf die Darstellung bezieht.

Moment, da ist noch was : wie siehts aus mit Zeit/Datum-Typen ? Date, Time oder Timestamp verwenden ? Für einen Tag bräuchte man doch wohl nur Date oder ist das auch egal ?

Guten Morgen Hansa,

bei Date, Time, Timestamp verwendest Du genau das, was Du auch brauchst. Im Unterschied zu Delphi (wo TDate letztenendes ein TDateTIme ist) benötigt Date und Time weniger Speicherplatz (32 bit anstelle 64 bit).

Bei Numeric und Decimal sieht es wie folgt aus:

Decimal(precision,scale): "precision" gibt die Anzahl der Stellen an die in der Variable gespeichert werden können, d.h. bei 15 werden max 15 Ziffern gespeichert. Davon werde allerdings die Anzahl der "scale" Ziffern noch abgezogen:

Decimal(15,2) bedeutet also insgesamt 15 Stellen, davon 2 nach dem Komma.

Die Speicherplatzbelegung (in Dialect 3) sieht wie folgt aus:


Du siehst bei (15,2) brauchst Du den gleichen Speicher wie bei (18,2) da alles in einem Int64 gespeichert und übertragen wird. Somit kannst Du auch die 3 weiteren Stellen eintragen.
In Delphi hat ein Currency folgenden Wertebereich:
[-922,337,203,685,477.5808..922,337,203,685,477.5808] Wenn ich richtig gezählt habe, sind das schon 15 Stellen vor dem Komma. Um diesen Typ richtig auszunutzen wäre in der Datenbank also ein Typ wie folgt zu deklarieren:

TCurrency=NUMERIC(18,3) {oder Decimal(18,3)}

Ich denke bei solchen Typen, die sowieso den Speicherplatz belegen, sollte man schon an den Grenzwert gehen (Außer es ließe sich mit einem Integer arbeiten).

Grüße
Lemmy

Lemmy hat folgendes geschrieben:

...Ich denke bei solchen Typen, die sowieso den Speicherplatz belegen, sollte man schon an den Grenzwert gehen...

Das denkst Du nicht nur, sondern machst es auch so. Numeric (9,2). Das stammt von Dir und ist eigentlich der Auslöser für das Thema hier. Na gut, werde die DB heute etwas polieren. Bei Statistiken ist 9,2 eventuell zu wenig. 15 Stellen sind aber auf jeden Fall ausreichend. Sollte ich aber einmal ein Programm für die Staatsschulden schreiben würde ich auch alles ausreizen was geht.

Noch etwas zu Numeric :

Wir hatten ein Numeric 15,2 Feld genommen, um GeldBeträge darzustellen. In der BDE klappte das, aber mit den DBX-Komponenten meldete das Dataset beim Ändern mancher Werte immer, daß der Wert von einem anderen benutzer geändert worden wäre.
Nach ein wenig Recherche zeigte sich das Problem:
Die DBX-Komponenten lesen Numeric-Werte teilweise falsch aus, aus 18,89 in der Datenbank wurde 18,90 auf dem Client.
Wir nehmen daher grundsätzlich nur Double Precisision auf DB-Ebene, die Formatierung erledigt Delphi.

Cu,
Udontknow

Hi,

Udontknow hat folgendes geschrieben:

aber mit den DBX-Komponenten meldete das Dataset beim Ändern mancher Werte immer, daß der Wert von einem anderen benutzer geändert worden wäre.

Sorry, aber was sind die DBX-Komponenten????

Grüße
Lemmy

DBX = Database Express (auch dbExpress), soll in Zukunft die BDE ersetzen.

Cu,
Udontknow

Hi,

aaahhh.... Ist aber hoch interessant, dass dbExpress mit diesen Typen Probleme hat.... Ein weiterer Grund native Komponenten einzusetzen....

Grüße
Lemmy

was soll denn bei nativen Komponenten anders sein, da gibts auch Bugs

Klar gibts bei denen auch Bugs. ABer bei all den Bugs die die IBX bisher hatten ist mir keiner bekannt, bei dem Daten verfälscht werden. Das sind Fehler, die kaum jemand rausfindet, wenn die Transaktion hängen bleibt merkt das jeder.

Grüße
Lemmy