Datenerfassung mit Firebird Datenbank

[Jens Hartmann]

Das mit der Domain, wenn ich es verstanden habe, wird genutzt um später verschiedenen Spalten, die die selbe Charaktaristik haben, die gleiche Domain zu geben, um es einfacher zu haben die Eigenschaften der Spalten zuzuweisen.

Zitat:

Zitat:

Da haue ich schnelle eine Zwischenfrage rein:

Ist Char(n) nicht schneller als VarChar(n) und bei weitgehend gleich breiten Zeichenketten besser?

Also, das mit Char und VarChar habe ich so verstanden, und steht so in der Doku

In der Praxis sollten Sie eine Regel beachten: verwenden Sie nur CHARs, wenn Strings mit wenigen Zeichen gespeichert werden sollen; die Ausnahme der Regel ist, wenn Sie mit Zwischentabellen arbeiten, die für den Datenexport von prn-Dateien mit festen Längen benötigt werden. Dann sind Felder mit festen Längen von Vorteil.

Tatsächlich benötigen VARCHAR-Spalten mehr Speicherplatz als CHAR-Spalten, da bei der Speicherng eines VARCHARs, InterBase/Firebird zwei Bytes hinzufügt, die anzeigen, wie groß der VARCHAR tatsächlich ist.

ALso wird ein CHAR tatsächlich mit weniger Paltzbedarf gespeichert. Wenn jedoch ein SELECT auf einer VARCHAR-Spalte erfolgt,schneidet InterBase/Firebird das 2-Byte-Polster ab und speichert den Wert. Wenn ein SELECT auf eine CHAR-Spalte erfolgt, gibt InterBase/Firebird den Wert und die "Leerzeichen" zurück. Also muss die Speicherung der zwei Bytes in einem CHAR gegen die nachträgliche Entfernung der Leerzeichen auf der Clientseite abgewogen werden. Diese beiden Bytes sind jedoch bei der heutigen Hardware so vernachlässigbar, dass sie keinen Einfluss auf die Datenbankgeschwindigkeit haben. Dies kann jedoch nachteilig bei der Definition von kurzen Textfeldern sein.

[Jens Hartmann]

Jetzt ist mir aber gerade nochwas aufgefallen, wenn ich jetzt Datum und Uhrzeit durch die Datenbank eintragen lasse, habe ich doch ein Problem, wenn mal die Datenverbindung zur Einbruchmeldeanlage (EMA) gestört ist.

Die EMA hat einen gewissen Datenpuffer, der dem Drucker zugeordnet ist, diesen kann ich auch nicht beeinflussen, das heißt, ist die Datenverbindung gestört, und wird zu einem späteren Zeitpunkt wieder Instandgesetzt, werden aber die noch im Puffer vorhandenen Daten ausgegeben.

Dies müsste ja dann automatisch zur Folge haben, das diese mit einem falschen Time/Date Format in die Datenbank eingetragen werden, und somit meine Ereigisse durcheinander sind.

Oder habe ich jetzt einen Denkfehler

[Chemiker]

Hallo Jens Hartmann,

Zitat von Jens Hartmann:

Das mit der Domain, wenn ich es verstanden habe, wird genutzt um später verschiedenen Spalten, die die selbe Charaktaristik haben, die gleiche Domain zu geben, um es einfacher zu haben die Eigenschaften der Spalten zuzuweisen.

Genau. Das erleichtert das Arbeiten z.B. beim Ändern der Datengröße z.B. hast Du 2 Felder mit VarChar 50 wenn Du Sie jetzt auf 60 ändern muss, dann ist nur eine Änderung an der Domain erforderlich. Da Du wahrscheinlich nur mit einer Tabelle arbeitest ist das aber zu vernachlässigen.
Wenn Du aber ein Warenwirtschaftssystem hast kann das schon eine Menge arbeit machen und ist Fehler anfällig.


Bis bald Chemiker

[Chemiker]

Hallo Jens Hartmann,

Zitat von Jens Hartmann:

Oder habe ich jetzt einen Denkfehler

Wenn das Datum und die Uhrzeit von der EMA geliefert wird, dann benutze das und schreibe es in die Datenbank.
Da hatte ich wohl ein Denkfehler, ich bin davon ausgegangen das Dein Programm das Datum/Uhrzeit für den Datensatz generiert.

Bis bald Chemiker

[Jens Hartmann]

Ne, das macht die EMA, genauso wie alle anderen Zentraletypen auch.

Danke, du hast mir sehr geholfen.

Morgen Früh kümmer ich mich um den Zugriff aus Delphi.

Schönen Abend noch.

[Chemiker]

Hallo Jens Hartmann,

vielleicht noch eins, wenn es geht versuche die Daten von der seriellen Schnittstelle so wie sie sind in die Datenbank reinzuschreiben.
Die Interpretation würde ich erst nach dem Lesen der Datensätze durchführen, z.B. für die Anzeige oder Drucken usw.
Das hat den Vorteil, dass die Daten relativ schnell in der Datenbank abgelegt werden können.

Bis bald Chemiker

[alex517]

Hallo Jens,

du hast, wie ich gesehen habe, in den Feldnamen '.' und '\' verwendet.
Damit kannst du ggf. Probleme bekommen.
Ich habe auch schon erlebt, dass jemand ein '€' im Feldnamen hatte
und damit anschließend die Datenbank nicht wieder öffnen konnte.
Auf jeden Fall wirst du diese Feldnamen immer in Anführungsstriche setzen müssen.
Damit erhöht sich nicht unbedingt die Lesbarkeit der SQL-Anweisungen.

Meine Empfehlung:
Nur Großbuchstaben A..Z, Ziffern 0..9 und den Unterstrich für Feldnamen verwenden.
Keine Sonderzeichen oder Umlaute.

Desweiteren keine Standard Keywords / reserved Keywords als Feldnamen verwenden.

alex

[Jens Hartmann]

Danke, das kann ich ja ändern mit den Namen,

zu deiner Sache mit den kompletten Datensätzen einlesen ohne sie zu verarbeiten, Also lese ich den Datensatz ein, und verarbeite Ihn nicht, dann ist aber die Frage, wie ich den Inhalt von Datum und Uhrzeit komme.

Also müsste ich ja den Datensatz komplett einlesen, und bei der Abfrage für´s Anzeigen oder Drucken den Datensatz zerplügen.

Oder, wie.

Der Datensatzt, hat ja folgenden Aufbau und es kann auch sein, das wie in dem Bild mehrere Einträge aufeinmal kommen.

[khh]

Zitat von Jens Hartmann:

Das wäre sicherlich möglich, nur ist halt meine Frage ob es Sinn macht, wenn ich das Datum ja eh in dem Datensatz mitgeliefert bekomme.

ist meiner Ansicht nach unnötig, da du das Datum schon hast.
Also einfach alles in eine einzige tabelle und die DS mit eienr ID versehen , fertig

Gruss KH

[alex517]

Die eingelesenen Daten sollten schon über das Delphi-Programm in die
einzelnen Ereignisse zerlegt und als einzelne Datensätze (je Ereignis)
gespeichert werden.
Was das Datum und die Uhrzeit anbetrifft, sollten zum einen die
aus der Anlage gemeldeten Werte und darüberhinaus der Timestamp
des Inserts in die Datenbank gespeichert werden.
Wie du schon selbst festgestellt können diese Angaben durchaus differieren.

In unseren Anwendungen haben so gut wie allen Tabellen die Felder

SQL-Code:

DC TIMESTAMP, /*Date Create */
DM TIMESTAMP, /*Date Modified  */
UC VARCHAR(), /*User Create  */
UM VARCHAR(), /*User Modified  */

die nur durch die Datenbank-Trigger gesetzt werden.
Hat schon häufig geholfen Problemen zu lösen oder
die Aussagen von Kunden zu "überprüfen".

alex