Config für DB aus DB selber

[cltom]

Hallo,

eine konzeptionelle/Stil-Frage: wo legt ihr die für SQL-Zugriffe notwendigen Namen der Tabellen sowie der Felder ab? Denkbar sind wohl:

- hart im Quellcode (wahlweise in einer eigenen Unit, die die Strings führt)
- in einer separaten (Text)Datei, die eingelesen wird

oder auch:

- aus der/einer anderen DB selber?

Spricht da was dagegen: eine Art config-Tabelle mit allen Namen der Felder und einem Index, in welcher Tabelle das Feld zu finden ist. Macht das Sinn? Dann lese ich bei Programmstart einmal die Liste von Tabellen-Namen ein und einmal die Liste von Feldnamen. In der Applikation könnte man das einfach in arrays of string werfen. Klasse lesbar wird es dort dann nicht, weil ein SQl-Statement dann nur noch MyNames[TableIndex, ColumnIndex] enthält und dann nicht mehr im Quellcode leicht sichtbar ist, auf welchen Feldnamen ich zugreife.

Vorteil: es liegt konsequent alles in der DB.
Nachteile: es hat ein wenig "zirkulären" Charakter. Dass man ein Feld dann in der gleichen Datenbank zwei mal ändern muss und das natürlich anfällig ist auf Fehler (Feldnamen geändert aber nicht in der config-Tabelle) - diesen Effekt hat man wohl bei jeder anderen Variante auch.

Danke für Eure Erfahrungen und Sichtweisen!

grüße
thomas

[haentschman]

Moin...

Zitat:

wo legt ihr die für SQL-Zugriffe notwendigen Namen der Tabellen sowie der Felder ab?

Meine SQL liegen als Dateien in einem Ordner im Projekt. Die SQL werden dann als Ressource eincompiliert...fertsch.
Das gilt sowohl für die SQL für das Programm als auch für die DDL SQL für die DB.

Siehe:
https://www.delphipraxis.net/190316-...e-creator.html

[Werbung OFF]

[cltom]

Zitat von haentschman:

Moin...

Zitat:

wo legt ihr die für SQL-Zugriffe notwendigen Namen der Tabellen sowie der Felder ab?

Meine SQL liegen als Dateien in einem Ordner im Projekt. Die SQL werden dann als Ressource eincompiliert...fertsch.
Das gilt sowohl für die SQL für das Programm als auch für die DDL SQL für die DB.

Siehe:
https://www.delphipraxis.net/190316-...e-creator.html

[Werbung OFF]

Danke für die Rückmeldung!! Dh Du definierst die ganzen Statements und legst die separat ab. Du baust erst gar nicht in der Applikation ein SQL-Statement zusammen, wo Du die Tabellen- und Feldnamen brauchst? Hab ich das richtig verstanden?

Das Tool schau ich mir gleich mal an!

Edit: ok, ich seh's schon anhand Deines Tutorials: genau so: da ist gar kein SQL mehr drin. Man bindet das ganze Ding separat ein.

[cltom]

wobei, doch noch ein Verständnisproblem: wie löst man dann die Zuweisung zu einzelnen Variablen?

Also zB ein

SomeClass.SomeValue := ZQuery.FieldByName('SomeValue').AsInteger; oder auch umgekehrt:

ZQuery.ParamByName('SomeValue').AsInteger := SomeClass.SomeValue;
Wie kommt man da ohne die Namen der Felder aus?

[haentschman]

Zitat:

Du baust erst gar nicht in der Applikation ein SQL-Statement zusammen

Richtig. Die "Add" Orgien sind Geschichte. Der Vorteil einer Datei ist, daß man sie auch im bevorzugten DB Editor testen kann. (Parameter muß man bei sowas dann selbst setzen )

PS: Im Handbuch sind Delphi Beispiele wie man mit Ressourcen umgeht...

Zitat:

.FieldByName('SomeValue').AsInteger

...da mußt du mit leben.

Oder ein anderes System benutzen (z.B. Aurelius). Kommt auf den Aufwand an.
https://www.tmssoftware.com/site/aurelius.asp

[cltom]

Danke Dir! Ich schau mir Deine Applikation mal näher an! Prinzip scheint aber mal verstanden.

Zitat:

.FieldByName('SomeValue').AsInteger
...da mußt du mit leben.

Was dann natürlich das ursprüngliche Thema nicht ganz löst, weil ich dann ja erst recht wieder einen Haufen Strings im Quellcode verteilt hab (oder auch in eine separate Unit gepackt). Der Vorteil bleibt natürlich, dass man die SQL-Statements nicht erst zusammenbauen muss und durchtesten, ob sie richtig zusammengebaut sind. Das ist schon ein Vorteil.

[haentschman]

Zitat:

Ich schau mir Deine Applikation mal näher an!

...das geht auch zu Fuß. Die Oberfläche ist darumgebaut...wegen der Übersicht.
https://www.delphipraxis.net/49505-s...einbinden.html

[Uwe Raabe]

Zitat von cltom:

Was dann natürlich das ursprüngliche Thema nicht ganz löst, weil ich dann ja erst recht wieder einen Haufen Strings im Quellcode verteilt hab

Dann nutze halt statische Felder. Damit verlagerst du die Feldnamen zwar nur in die DFM, aber irgendwo müssen sie ja stehen. So hast du sie nicht im Quellcode wenn du das nicht willst.

[BerndS]

Ich habe mir ein kleines Tool geschrieben (verwendet z.B. SynEdit), mit dem man die Scripte erstellt und testen kann.

Weiterhin extrahiert das Tool aus der DB alle Tabellen und deren Feldnamen sowie SPs und Views in eine Include Datei.
Bespiel:

Delphi-Quellcode:

tnTEST = 'TEST';
fnTEID = 'TEID; // INTEGER
fnTENAME = 'TENAME'; // VARCHAR(40)

Diese wird von eine Konstanten Unit eingebunden.

Alle Tabellen fangen mit tn... und alle Felder mit fn... an.
In unserer DB sind die Feldnamen nie doppelt.

Vorteil, man kann sich nicht so leicht mit den Feldnamen vertun, wenn die als Konstanten vorliegen.
Mit dem Tool wird ein Script Datei erstellt, die für jede DB-Version ein Script enthält.
Nach dem Anmelden wird vom 1. User geprüft, ob ein Update nötig und möglich ist.

Die Datenbank hat eine extra Tabelle, welche die Versionsinformationen dafür enthält.

[cltom]

Zitat von Uwe Raabe:

Zitat von cltom:

Was dann natürlich das ursprüngliche Thema nicht ganz löst, weil ich dann ja erst recht wieder einen Haufen Strings im Quellcode verteilt hab

Dann nutze halt statische Felder. Damit verlagerst du die Feldnamen zwar nur in die DFM, aber irgendwo müssen sie ja stehen. So hast du sie nicht im Quellcode wenn du das nicht willst.

nun, dass ich das nicht will, wär zu viel gesagt. Ich hab mich gefragt, ob es elegantere Lösungen gibt. Mehr auch aus dem Bauchgefühl heraus, dass es bestimmt clevere Varianten gibt, die ich einfach nur nicht am Radar hab.