ADOQuery - SQLQuery ??

[haentschman]

Zitat:

Hihi, kann ich auch:

:P Der Möglichkeiten gib es verschiedene. Das Auslagern ist aus dem Quelltext ist das Entscheidende. :thumb:

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Wenn wir weiter darüber diskutieren wollen, sollten wir das in einen separaten Thread auslagern. :thumb:

[nahpets]

Zitat:

Zitat von haentschman (Beitrag 1368300)

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Richtig, und die übrigen Daten sind dann genauso veraltet.

Zuerst kommen die fertigen und durchgetesteten Statments in die Datenbank und dann die Daten.
Die erste Sicherung enthält damit immer die zur Datenbank passenden Statements. Eine veraltete Version gibt es nicht (es sei denn, irgendwer daddelt später noch an den Statements rum. Der bekommt dann aber Haue).
Davon abgesehen werden die Statements immer auch noch als Scripte zu den Quelltexten der Software gelegt (und ggfls. damit zusammen versioniert).

Ok, das ist ein vielfältiges Thema, über das man andernorts sicherlich mal 'ne "Grundsatzdiskussion" führen könnte, um ggfls. aus den bisher "erfundenen" Konzepten ein "allumfassendes" zu machen, das alle Vorteile der bisherigen Konzepte vereinigt und alle Nachteile ebendieser eleminiert.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1368295)

Dadurch kann ich die Statements erstmal "ausprobieren". Jedes hat 'ne eindeutige ID, über die es angesprochen wird.

Im Prinzip gefällt mir der Ansatz, nur der Zugriff über die wenig sprechende ID gefällt mir nicht. Aber bei deskriptiv hat wieder jeder andere Ideen.

Gruß
K-H

[nahpets]

Die ID schien mir das Sinnvollste für den Zugriff aus 'nem Programm zu sein.

In der Datenbanktabelle steht neben ID und SQL auch noch 'ne Beschreibung zum SQL, so dass man dort auch noch Sinn und Zweck nachlesen kann, ohne erstmal das Statement zu analysieren.

Im Programmquelltext steht an den Stellen, an denen ein Statment aus der DB geholt wird, immer auch ein entsprechender Kommentar (soweit sich nicht aus dem Quelltext bereits ein eindeutiger Hinweis ergibt).

Ein

Delphi-Quellcode:

qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

ist ein absolutes NoGo.

Entweder das ist in einer Prozedur oder Funktion mit einem sprechenden Namen gekapselt oder davor steht ein Kommentar.

Mindestens

Delphi-Quellcode:

// vollständige Lieferantenliste anzeigen.
qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

Für jemanden, der den Quelltext erstmalig liest, dürfen keine Fragen offen bleiben.

Wenn der erst in der Datenbank nachschauen muss, was für ein Statment denn da geholt wird, ist etwas grundlegend falsch.

[p80286]

Wie wäre es mit

Delphi-Quellcode:

const
  GETPERSONLIST=42;

.....
qry.SQL.Text := GetSQLStatement(GETPERSONLIST);
qry.Open;
 ...

Gruß
K-H

[nahpets]

Klar, kann man so machen.

Habe da mal 'ne eigene Klasse, abgeleitet von einer Datenbankkomponente gemacht. Die Klasse hatte u. a. die Attribute InsertID, UpdateID, DeleteID und SelectID. Dort stand dann die entsprechende ID.

Dann gab es die passenden Methoden dazu.

Von dieser Klasse waren dann die weiteren Klassen für Kunden ... abgeleitet. Sie hatten zusätzlich dann die entsprechend Attribute wie Name ...

Als Programmiere musste man für's Select dann nur noch die Get-Methode aufrufen. Für neue Daten halt New, Update ging über Set und Delete setzte nur einen Löschschalter und Löschdatum ... im Datensatz, da keine Daten physikalisch aus der Datenbank entfernt wurden.

Eigentlich war das für den Entwickler sehr transparent.

Er musste sich weder um die Zuweisung der Tabelleninhalte in die Attribute kümmern, noch um den umgekehrten Weg.

Das Einzige, was er machen musste, war: Die Inhalte der Attribute in die Anzeigemaske bringen bzw. die Inhalte der Anzeigemaske wieder in die Attribute der Klasse schieben.
Dafür waren die passenden Getter und Setter angelegt.
Und er musste natürlich, soweit erforderlich, die entsprechende Geschäftslogik und ggfls. Plausibilitätsprüfungen ..., implementieren.

Die Basisklasse war schon recht kompliziert und funktionierte zum Teil über RTTI, aber die Benutzung im Programm war dann beinahe schon banal einfach.

Schon interessant, was man mit RTTI und sinnvoller Vererbung für "schöne Schweinereien" machen kann. Da sieht man dann, wie leistungsfähig einen vernünftige Objektorientierung sein kann.

[p80286]

Die eigene Klasse liegt eigentlich früher oder später auf der Hand (DataModule). Aber wo kommt da RTTI in Spiel?

Gruß
K-H

[nahpets]

Die Klassen haben halt mehr oder weniger Attribute, die sich entsprechend in der Datenbanktabelle wiederfinden.

Über Namenskonventionen findet ein Mapping statt, so dass es nicht erforderlich ist, in den Statements für jede Klasse die Spalten und Wherebedingung für die Schlüsselspalten anzugeben. Dies wird alles zur Laufzeit von der Klasse über RTTI automatisch "geregelt".

Leider hab' ich keinen Zugriff mehr auf die Quellen, die sind bei 'nem ehemaligen Arbeitgeber entstanden, der inzwischen nicht mehr existiert.
Und an die genauen Details kann ich mich nicht mehr so wirklich erinnern (ist ca. 10 Jahre her), dafür war das dann doch etwas zu kompliziert, um es aus dem Stehgreif rekonstruieren zu können.

[xReva]

Danke für all die Hilfe ich habe es jetzt hinbekommen :)


Mfg Lucas

[haentschman]

:P Und wie sieht das Ergebnis aus?