Philipp/aki_prj23_transparenzregister
Philipp/aki_prj23_transparenzregister
1
0
Fork 0
mirror of https://github.com/fhswf/aki_prj23_transparenzregister.git synced 2025-05-14 10:28:46 +02:00
Code Issues Packages Projects Releases Wiki Activity

Added docs on FK and PK (#504)

Browse Source
This commit is contained in:
Philipp Horstenkamp 2024-01-03 18:30:35 +01:00 committed by GitHub
parent 797dd165a8
commit 6e0247c58c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 26 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
documentations/Ergebnisse/Abschlussbericht_und_Praesentation/PhHo/.gitkeep
View File

34
documentations/Ergebnisse/Abschlussbericht_und_Praesentation/PhHo/4-4-2-database-generator.md
View File

@ -1,13 +1,15 @@
### Database Generator (Philipp Horstenkamp) ### Database Generator (Philipp Horstenkamp)
Zur Definition eines Relationalen Datenbankschemas und zur Härtung gegen SQL-Injections wurde SQLAlchemy als SQL-Interface / Driver / Abstraction layer genutzt. Zur Definition eines relationalen Datenbankschemas und zur Absicherung gegen SQL-Injections nutzen wir SQLAlchemy.
SQLAlchemy sorgt dabei für ein Dialekt unabhängiges Interface, um unabhängig von der verwendeten Datenbank zu sein. Es dient als SQL-Interface, Treiber und Abstraktionsschicht.
SQLAlchemy bietet ein dialektunabhängiges Interface, um datenbankunabhängig zu arbeiten.
Auch wenn es seit einiger Zeit SQLAlchemy2 gibt haben wir uns entschieden Version 1.4 zu nutzen da es zur Version 2 nur wenig Dokumentation, externe Dokumentation und Beispiele gab. Obwohl SQLAlchemy2 existiert, entschieden wir uns für Version 1.4.
SQLAlchemy ist ein sehr mächtiges und beliebtes Werkzeug, leider ist die Projektdokumentation sehr undurchsichtig. Der Grund ist die begrenzte Dokumentation und weniger externe Ressourcen für Version 2.
Da aber SQLAlchemy1.4 zurzeit noch gewartet wird, ist dies für dieses Projekt kein Problem. SQLAlchemy ist ein mächtiges und beliebtes Tool, aber seine Projektdokumentation ist oft undurchsichtig.
Da SQLAlchemy1.4 jedoch noch unterstützt wird, stellt dies für unser Projekt kein Problem dar.
Hier ein kurzes Beispiel einer SQL-Definition via SQLAlchemy. Im Folgenden ein kurzes Beispiel einer SQL-Definition mittels SQLAlchemy.
```python ```python
import sqlalchemy as sa import sqlalchemy as sa
@ -47,7 +49,15 @@ class Company(Base):
founding_date = sa.Column(sa.Date, nullable=True) founding_date = sa.Column(sa.Date, nullable=True)
``` ```
### TODO PK - FK Definition Primärschlüssel und Fremdschlüssel (*PK*/*FK*) werden durch SQL-Alchemy-Klassen definiert.
Wir setzen `primary_key=True` für jede PK-Spalte, was auch über `__table_args__` möglich ist.
`__table_args__` umfasst alle Eigenschaften, die üblicherweise durch Tabelleneinstellungen definiert werden.
In unserem Fall beinhalten diese meist Constraints zur Datenvalidierung.
Fremdschlüssel definieren wir mit dem zusätzlichen Argument `sa.ForeignKey("district_court.id")`.
Dies zeigt an, dass eine Spalte einen FK zu einer anderen Spalte in einer anderen Tabelle darstellt.
In unserem Beispiel ist es die `id`-Spalte der Tabelle `district_court`.
Da wir in unserer Softwarearchitektur fast ausschließlich Daten einfügen, verzichten wir auf die Definition von `on_delete` und `on_update`.
Die einzige Tabelle, die Änderungen unterliegt, verwendet keine FKs.
Natürlich ist es manchmal sinnvoll SQL-Tabellen dynamischer und mit wenig Code-Duplication zu generieren. Natürlich ist es manchmal sinnvoll SQL-Tabellen dynamischer und mit wenig Code-Duplication zu generieren.
Eine Möglichkeit dazu ist die folgende Definition in der die Union einiger Teildefinitionen als Dictionary. Eine Möglichkeit dazu ist die folgende Definition in der die Union einiger Teildefinitionen als Dictionary.
@ -71,9 +81,9 @@ AnnualFinanceStatement = type(
) )
``` ```
Das Anlegen der Klassen alleine reicht nicht aus, um diese in einer SQL-Datenbank anzulegen. Das bloße Anlegen der Klassen genügt nicht, um sie in einer SQL-Datenbank zu erstellen.
Diese müssen über das `Base`-Objekt wie folgt Initialisiert werden. Sie müssen über das `Base`-Objekt wie folgt initialisiert werden:
Dabei werden nur fehlende Tabellen initialisiert. Nur fehlende Tabellen werden dabei initialisiert.
```python ```python
Base.metadata.create_all(db.bind) Base.metadata.create_all(db.bind)
@ -90,5 +100,5 @@ Das resultierende SQL-Schema sieht dann wie folgt aus:
:page-index: 1 :page-index: 1
``` ```
Es gibt Schema verändernde, versionierende Erweiterungen für `SQLAlchemy`, wie `Alembic` oder `SQLAlchemy-mirgrate`. Es existieren schemaändernde, versionierende Erweiterungen für `SQLAlchemy`, wie `Alembic` oder `SQLAlchemy-migrate`.
Durch ein Softwaredesign welche die Produktivtabellen aber regelmäßig reinitialisiert wird dies unnötig. Unser Softwaredesign, das die Produktivtabellen regelmäßig reinitialisiert, macht diese jedoch überflüssig.

0
documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/.gitkeep
View File

5
documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/prompts.md
View File

@ -3,9 +3,12 @@ Halte dich inhaltlich an die Vorgaben.
Korrigiere aber bitte, Grammatik, Zeichensetzung und Stil. Korrigiere aber bitte, Grammatik, Zeichensetzung und Stil.
Bitte kürze / teile die Sätze wenn möglich. Bitte kürze / teile die Sätze wenn möglich.
```markdown
```
Bitte gib mir die überarbeitete version in Markdown (md) aus. Bitte gib mir die überarbeitete version in Markdown (md) aus.
Dieses sollte in einem md codeblock angezeigt werden. Dieses sollte in einem md codeblock angezeigt werden.
Bitte fange für jeden Satz eine neue Zeile an. Bitte fange für jeden Satz eine neue Zeile an.
Sollten Fragen offen bleiben schreibe mir bitte einen kurzen Verweise auf den md block. Sollten Fragen offen bleiben schreibe mir bitte einen kurzen Verweis nach md Code-Block.