Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Benennung von Abfragen und Tabellen (Nomenklatur)

Begonnen von NeuRose, August 06, 2021, 11:24:50

⏪ vorheriges - nächstes ⏩

NeuRose

Hallo, ich habe eine umfangreiche Datenbank mit vielen Abfragen die ebenfalls Unterabfragen haben.
Und Berichte, die auf viele unterschiedliche Abfragen (incl. Unterabfragen) laufen.

Jetzt versuche ich eine Nomenklatur umzusetzen. Wie benennt man denn am besten Unterabfragen usw.
(d.h. welche Bezeichnungsweise hat sich zum besseren Verständnis und Lesen einer Datenbankstruktur etabliert?)


NeuRose

Danke dafür, aber wie oben beschrieben suche ich eher Bezeichnungen aus der Praxis für (s.u.).
(... also etwas anspruchsvoller, bzw. Paxiserfahrungsnäher!)

Beispiel:
3. Wird fürn Bericht verwendet: SQL5 mit übergebenen Parameter
2. Resultat 6SQL: Gibt die gewünschte Query aus aber in Beziehung mit 1-3 über die 5SQL und mit übergebenen Parameter über ein Formular.
1. Resultat 5SQL: Benutzt SQL 1- 3

4SQL: Gibt die gewünschte Query aus.
3SQL: Benutzt SQL2
2SQL: Benutzt SQL1
1SQL: Abfrage 1 benutzt tbl1

3tbl: Beziehung mit 2tbl - Klimaschutzrelevanz
2tbl: Beziehung mit 1tbl - verknüpft Gasen
1tbl: Alle CO2 Formen


d.h. hier z.B. wie nenne ich die?

ebs17

Eine Variante, die ich nutze, ist, dass eine Unterabfrage im Normalfall auch wirklich als Unterabfrage in SQL in der Abfrage vorhanden ist.
Eine (Unter)Abfrage als gespeichertes eigenes Objekt anzulegen käme nur in Frage, wenn diese in Nachfolge mehrfach genutzt wird. Das passiert aber dramatisch selten, da Abfragen für gutes Design und gute Laufzeiten stets schlank und flach gehalten werden (nur die Felder und die Datensätze, die wirklich benötigt werden). Eine solche jeweilige Fall-Spezialisierung lässt eine Mehrfachnutzung unwahrscheinlich sein.
Grundlagen - SQL ist leicht (6) - Komplexe Abfragen schreiben und lesen

Wenn man dann noch zusätzlich Abfrage-Datenherkünfte für Formulare, Listenfelder usw. direkt die jeweilige RecordSource/RowSource als SQL schreibt (nebenbei ist der SQL-Code dann beim jeweiligen Objekt und somit zugeordnet und auch mit dem Objekt kopierbar), entspannt sich das Verwaltungs- und Benennungsproblem für die Abfrageobjekte im Navigationsfenster erheblich.
Mit freundlichem Glück Auf!

Eberhard