Datenerfassung mit Firebird Datenbank

[Jens Hartmann]

Hallo, habe das jetztmal soweit alles versucht zu sortieren und zu verarbeiten. Habe mir jetzt Firebird 2.1 und IBexpert installiert und versucht, das ganze Problem anzugehen.

Meine erste Frage, wäre eigendlich jetzt folgende.

Ich habe jetzt gerademal probiert, mit IB eine Tabelle zu erstellen, das denke ich sollte auch soweit kein Problem.
Jetzt nur meine Überlegung: Ich möchte ja später die Daten meiner Einbruchmeldeanlage in dieser Datenbank speichern.

Datensatz sieht so aus

Ereignisnr. Datum Uhrzeit Ereignis Teilnehmer Bereich

1000 23.02.2009 17:43 Extern Scharf IE:0 B1 SE Markt Verwaltung

Die Ereignisnummer, kann sich allerdings wiederholen, da die Ereignisspeicher der Zentrale, nur 10000 Ereignisse kann.

Ich würde jetzt vor das Ereigniss eine ID setzten, lasse ich die Daten jetzt komplett in eine Tabelle schreiben, mache ich Tabellen so nach der Art 2008 , 2009 , 2010 oder 2009Januar , 2009Februar, oder so gar Tagesbezogen.

Ich weiß nicht, am einfachsten wäre es, alles nacheinander in eine Tabelle, aber macht das Sinn

[edit=mkinzler] Mfg, mkinzler[/edit]

[mkinzler]

Ich würde die Eindeutigkeit auf das Feld Datum ausweiten

[Jens Hartmann]

Also keine zusätzliche ID?

[mkinzler]

Als PK würde ich natürlich einen synetischen Schlüssel verwenden

[Jens Hartmann]

Also den Primärschlüssel als Zähler und dann den Datensatz dahinter.

Und wenn ich das mit dem Datum von Dir verstanden habe, Also für jedes Datum eine neue Tabelle

[mkinzler]

Nein, war nicht so gemeint; würde ich auch nicht machen. Ich meinte nur, dass die Ereignisnummer immer nur in Verbindung mit dem Datum verwendet werden sollte

[Jens Hartmann]

Ja, dann wäre es aber vermutlich besser, die Ereignisnummer an sich ganz entfallen zu lassen, oder halt nur als Teil vom Datensatz, da es passieren kann (nach einem Firmwareupdate der Zentrale wird der Ereignisspeicher auf 0000 gesetzt) das auch an ein und dem selben Tag die selben Ereignisnummer vorhanden ist.

Ist zwar selten, kann aber vorkommen.

Also, kann ich die Daten alle in eine Tabelle schreiben.

Bis zu wieviele Datensätze bekomme ich den da unter, ohne Probleme.

[mkinzler]

Zitat:

Bis zu wieviele Datensätze bekomme ich den da unter, ohne Probleme.

Kommt auf deinen Plattenplatz an

[Jens Hartmann]

Das ist mir auch klar. Es tut mir Leid, wenn die Frage vieleicht doof ist, aber ich versuche mich gerade einzuarbeiten und da wäre es halt schön, wenn man eine gewisse Richtung hätte worauf ich achten müsste.

Es ist auch von mir nicht böse gemeint, aber mit den kurzen knappen antworten, komme ich nicht so richtig weiter. Ich weiß auch das die Festplattengröße eine Rolle spielt, aber bislang, habe ich die Daten in TXT Dateien gespeichert, und da brauchte ich mir keine Gedanken über die Festplattengröße zu machen, bei max. 100KB pro Tag, dauert es schon ewig, bis da 80GB und mehr voll sind.

Für mich wäre wichtig zu verstehen, worauf ich achten sollte.

Und wie gesagt, ist nicht böse gemeint, aber so antworten wie

Kommt auf die größe deiner Platte an, die bringen mich nicht weiter. Weil das weiß so gar ich.

Sorry, wenn ich vieleicht manchmal doof frage, aber bei den vielen Möglichkeiten, muss man einfach irgendwo eine gewisse Richtung haben.

Danke für Euer Verständnis.

Gruß

Jens

[Chemiker]

Hallo Jens Hartmann,

vielleicht mkinzler bitten, ob er das Thema abspalten kann und unter dem Themengebiet Datenbank schieben kann.

Also ich würde eine eindeutig ID nehmen die nichts mit der Ereignisnummer zu tun hat, am besten durch einen Generator / in Verbindung mit einem Trigger selber anlegen lassen von der Datenbank.
Eine Frage zu dem Datum ich habe es so gelöst das auch das automatisch von der Datenbank erzeugt wird, also wenn ein neuer Datensatz in der Datenbank angelegt wird, wird automatisch das aktuelle Datum vergeben.

Die Tabelle für die Datenbank legst Du mit IBExpert an.

Eine neue Tabelle muss Du nicht für jedes Jahr anlegen sonder Du kannst mit einer Query-Abfrage das Lösen.
Ich habe hier eine Test-Datenbank mit 2,7 Mio. Datensätzen nur zum Spielen und Testen

Bis bald Chemiker

[mkinzler]

Zitat:

vielleicht mkinzler bitten, ob er das Thema abspalten kann und unter dem Themengebiet Datenbank schieben kann.

Könnte ich machen; aber auch jeder andere Moderator.

Zitat:

Es ist auch von mir nicht böse gemeint, aber mit den kurzen knappen antworten, komme ich nicht so richtig weiter. Ich weiß auch das die Festplattengröße eine Rolle spielt, aber bislang, habe ich die Daten in TXT Dateien gespeichert, und da brauchte ich mir keine Gedanken über die Festplattengröße zu machen, bei max. 100KB pro Tag, dauert es schon ewig, bis da 80GB und mehr voll sind.

Viel größer ist ein Datensatz in einer Datenbanktabelle auch nicht. Ich meinte mit meiner Aussage, das du dir hierbei auch keinen Kopf machen musst.

[Jens Hartmann]

Danke erstmal, das ihr mir das nicht übel genommen habt, und daher, bitte ich dich mkinzler, das Thema wirklich vieleicht abzuspalten und unter Datenbank zu erstellen.

So jetzt aber zum Thema, ich habe jetzt eine Datenbank erstellt. Das geht endlich mit Deutscher Version und Deutscher Dokumentation auch ganz gut.

Ich habe das mit den Generatoren auch schon gesehen, nur noch nicht genau verstanden. Aber, ich habe jetzt die Möglichkeit in einer mir Verständlichen Sprache nachzulesen.

Und zu der Sache mit dem Datum...

Chemiker hat geschrieben;

Zitat:

Eine Frage zu dem Datum ich habe es so gelöst das auch das automatisch von der Datenbank erzeugt wird, also wenn ein neuer Datensatz in der Datenbank angelegt wird, wird automatisch das aktuelle Datum vergeben.

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.

[mkinzler]

Zitat:

Ich habe das mit den Generatoren auch schon gesehen, nur noch nicht genau verstanden. Aber, ich habe jetzt die Möglichkeit in einer mir Verständlichen Sprache nachzulesen.

Du kannst dir Generatoren als tabellenunabhängige Variablen vorstellen, in denen der nächste Wert steht. Diese können mit der Semaphorenfunktion GEN_ID() erhöht werden.

[Jens Hartmann]

Also, kann wenn ich das jetzt richtig verstanden habe, vorher in meiner Paradox Datenbank, hatte ich in meine Tabelle einer Variable mit dem Format Zähler, diese wurde ständig hochgezählt und bei gelöschten Datensätzen auch nicht mehr frei gegeben.

Ich will mal kurz beschreiben, wie ich meine Tabelle jetzt aufgebaut habe:

1 ID BIGINT als Generator
2 Nr INTEGER
3 Datum DATE
4 Uhrzeit TIME
5 Ereignis VARCHAR
6 Teilnehmer VARCHAR
7 Bereich VARCHAR

Jetzt möchte ich die Datensätze in die Datenbank einfließen lassen und versehe jeden einzelnen mit einer ID die durch den Generator automatisch erzeugt wird.

Naja ich denke so könnte das gehen.

[Chemiker]

Hallo Jens Hartmann,

bei der Firebird- Installation wird auch eine DEMO-Datenbank mit den Namen:
FB2_0Datenbank\examples\empbuild\EMPLOYEE.FDB
mit installiert. Dort kannst Du z.B. in der Tabelle: CUSTOMER einen Trigger sehen der das Feld CUST_NO mit einem Generator füllt.

Bis bald Chemiker

[mkinzler]

Zitat:

1 ID BIGINT als Generator

Nicht als Generator, sondern generatorunterstützt.
Hierbei hast du verschiedene Möglichkeiten:
-Setzen des Wertes durch einen Trigger ( der sich dem Generator(Sequenz) bedient (kannst du mit samt des enerators von IBExpert erzeugen lassen)
-Inline:

SQL-Code:

insert into <Tabelle> ( ID, ...) values ( gen_id( <generator>, <Schrittweite>), ...) returning ID;

-Mit Sequenzkomponente

[Chemiker]

Hallo Jens Hartmann,

das Datum und die Uhrzeit würde ich zusammenfassen als TimeStamp.

Bis bald Chemiker

[Jens Hartmann]

Habe die Demodatenbank mal geladen, also ist es so, das der Generator durch den Trigger beeinflußt wird, der

wenn ich das richtig sehe, durch die Funktion Befor Insert gesetzt wird.

[mkinzler]

Ein Trigger ist ein Stück Code, welches auf Grund eines Ereignisses aufgerufen (getriggert) wird.
In diesem Fall vor dem Insert.

[Jens Hartmann]

Das Datum als TimeStamp, habe ich auch gedacht. Allerdings möchte ich das Datum und die Uhrzeit gerne nachher getrennt Anzeigen können, oder nach suchen lassen, macht es da Sinn, diese zusammen einzutragen, wenn ich Sie später getrennt benötige.

Zitat:

Ein Trigger ist ein Stück Code, welches auf Grund eines Ereignisses aufgerufen (getriggert) wird.
In diesem Fall vor dem Insert.

Also, das habe ich jetzt so weit verstanden, Der Trigger in diesem Fall SET_CUS_NO wird vor dem Insert ausgeführt, und in diesem Trigger der GEN_CUST_NO hochgezählt. Genauso, könnte ich somit weiter Funktionen ausführen lassen,

Also auch das aktuelle Datum, wie Chemiker eben vorgeschlagen hat mit Eintragen lassen.

Das heißt, ich könnte dann ja wirklich Datum und Uhrzeit von der Datenbank erzeugen lassen, und übernehmen, und müsste nur noch die eigentlichen Daten einbinden.

[mkinzler]

Ja. hierfür gibt es auch Kontextvariablen ( CURRENT_DATE, CURRENT_TIMESTAMP, ...)
Auf ein Ereignis kann man auch mehrere Trigger binden, deren Reihenfolge man dann mit POSITION setzen kann

[Chemiker]

Hallo Jens Hartmann,

beim Datum ist es noch einfacher. Du hast die Möglichkeit unter dem Feld für das Datum/Uhrzeit einfach als Default ‚NOW’ eingeben und schon wird das Datum/Uhrzeit in den Datensatz reingeschrieben.

Bis bald Chemiker

[Jens Hartmann]

Also, wenn ich das jetzt so richtig gemacht habe, dann sieht das ganze jetzt in etwa so aus

[Chemiker]

Hallo Jens Hartmann,

ich habe zuvor die Domänen angelegt. Warum ist der Bereich als Char und nicht als VarChar deklariert?

Bis bald Chemiker

[Jens Hartmann]

Bereich habe ich schon umgeändert in VARCHAR.
und wenn das OK ist, habe ich auch Datum und Uhrzeit in zwei Spalten geteilt und beide auf 'NOW' gesetzt.

[Satty67]

Da haue ich schnelle eine Zwischenfrage rein:

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

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

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:

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. :gruebel:

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

[khh]

Zitat:

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

[Jens Hartmann]

Das hört sich zumindestens mal so an, als hätte ich verstanden worum es geht.

KH hat geschrieben

Zitat:

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

Also, nutze ich das Datum aus meinem Datensatz um später eine Möglichkeit der Abfrage zu haben, wann was passiert ist.

Alex hat geschrieben

Zitat:

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.

Daraus folgere ich, das ich zusätzlich noch eine Spalte machen sollte, die mit dem Trigger gesetzt wird, um später erkennen zu können, ob eine Differenz zwischen dem Ereignissdatum und dem Eintragdatum besteht.

Außerdem. müsste ich also den Datensatz doch komplett zerlegen, und auch die Ereigniss in die Untergruppen Ereignis, Teilnehmer, Bereich zerlegen.

[Jens Hartmann]

So, ich habe jetzt die Datenbank angepasst und versucht drauf zuzugreifen, eins ist mir allerdings noch unklar, und ich bekomme auch beim ausführen, eine Fehlermeldung.


Wenn ich folgende SQL-Abfrage ausführe..

SQL-Code:

SELECT * FROM Securdat.fdb

Dann kommt eine Fehlermeldung, das ganze klingt für mich auch logisch, weil woher, soll das Programm wissen, das es auf die Tabelle MB256PLUS aus der Datenbank Securdat zugreifen soll?

[mkinzler]

-Verbindung zur Datenabnk Securdat.fdb aufbauen
-

SQL-Code:

SELECT * FROM  MB256PLUS

[Jens Hartmann]

Ich denke das habe ich gemacht

Delphi-Quellcode:

{Datenbank}

{Datenbankpfad zuweisen}
procedure TFUebung.Button8Click(Sender: TObject);
var
s :String;
begin
  Query1.Active := false;
  SelectDirectory('Wählen Sie das Datenbankverzeichnis aus ' + 'wo sich Ihre Datenbank befindet',' ',s);
  Edit1.Text := s+'\Securdat.fdb';
  Query1.DatabaseName := Edit1.Text;
end;

{SQL-Abfrage starten}
procedure TFUebung.Button7Click(Sender: TObject);
begin
  Query1.SQL := Memo1.Lines;
  Query1.Active := true;
end;