Datenbankstruktur "Drill-Exemption"

[Forumsgast]

Hi zusammen,

ich bräuchte hier mal eine kleine Konzeptionierungsstütze. Da ich seit sechs Jahren in der Systemadministration bin und seit dem nur noch wenig programmiere ist das alles ein wenig eingerostet. Zu meinem Projekt: Ich bin IT Admin auf einem Schiff. Hier werden wöchentlich Seenotrettungsübungen durchgeführt, von welchen bestimmte Besatzungsmitglieder befreit werden können. Hierfür würde ich gerne eine Seite auf einem meiner Server mit inlineedit-Tabellen hosten. Hier einmal die DB Struktur die ich mir so überlegt habe:

- Tabelle Drills: ID, Datum, Ort, Typ, Startzeit, Abmeldeschluss
- Tabelle Manning Numbers (jedes Crewmitglied hat eine Besatzungsnummer): ID, ManNo, Department, Duty, Gruppen-ID, LastDrill, MissedDrillsCount, DoNotExempt
- Tabelle Gruppen (jeweils ein Mitglied aus einer Gruppe darf pro Drill max. befreit werden): ID, Typ, Location

- Tabelle DrillExempted: DrillID, ManNoID, Refused

Die letzte ist die fragwürdige Tabelle. Die Drills werden natürlich immer mehr und bei jedem Drill muss abgespeichert werden wer befreit (worden) ist und wer nicht. Macht es Sinn eine "Kombinations-Tabelle" "DrillID & ManNoID" anzulegen? Mir fällt keine bessere Möglichkeit ein. Daher die Frage an die geübten / routinierten Datenbankleute hier wie man so eine wachsende, dynamische Zuordnungsgeschichte aus zwei Tabellen am Besten realisiert.

Grüße & Besten Dank für eure Hilfe!

[Forumsgast]

Ob es sinnvoll ist solltest du dir mit deiner langjährigen Erfahrung selbst beantworten können.
"jede Woche ca. 50 neue Einträge" - Na, das scheint mir kein Problem zu sein.

Nehmen wir an die Datenbank soll nicht mehr als 1 Million Datensätze haben, dann darf dein Schiff 357 Jahr unterwegs sein, ein Zeitraum den du wohl nicht erleben wirst. Eine Million Datensätze ist für eine Datenbank zudem eine Lachnummer.

[Forumsgast]

Danke für die Antwort. Recht hast du. Falls sich noch jemand äußern möchte ob es für die Implementierung geschicktere Konzepte gibt gerne raus damit.

[Forumsgast]

Hallo,

also generell würde ich die Namensgebung vereinheitlichen:

• keine Großbuchstaben in Tabellennamen oder Spaltennamen => Worttrennungen durch Unterstriche (ist eher üblicher)
• entweder komplett englisch oder komplett deutsch

Und klar, eine Beziehungstabelle macht immer Sinn. Refused soll dann ein boolscher Wert sein, ob das Crew Mtiglied teilgenommen hat oder nicht?

Aufpassen bei boolschen Werten: So einen Datentyp gibt es in SQL nicht. Selbst wenn du unsigned INT(1) nimmst, kannst du immer noch Zahlen von 0 bis 9 darin haben.


MFG

derwunner

[Forumsgast]

Ok, dann fühle ich mich mal bestätigt. Danke für die Tips!

[Forumsgast]

Aufpassen bei boolschen Werten: So einen Datentyp gibt es in SQL nicht.

Das ist nicht richtig! Siehe z.B. https://www.postgresql.org/docs/9.5/...e-boolean.html

[Forumsgast]

Aufpassen bei boolschen Werten: So einen Datentyp gibt es in SQL nicht.

Schmarrn.

andreas@[local]:5433/test*# create table demo(bool_geht_doch bool default false);
CREATE TABLE
andreas@[local]:5433/test*# insert into demo values (default);
INSERT 0 1
andreas@[local]:5433/test*# insert into demo values (true);
INSERT 0 1
andreas@[local]:5433/test*# select * from demo;
 bool_geht_doch
----------------
 f
 t
(2 rows)

andreas@[local]:5433/test*#

[Forumsgast]

Das funktioniert so sogar unter mysql, dort ist es dann aber 0 1.

[Forumsgast]

Kann man dann bestimmt addieren, oder?

andreas@[local]:5433/test*# select 'false'::bool + 'true'::bool;
ERROR:  operator does not exist: boolean + boolean
LINE 1: select 'false'::bool + 'true'::bool;
                             ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.
andreas@[local]:5433/test!#

[Forumsgast]

Deine Frage ist nicht Zielführend und hat mit dem Ausgangsthread nichts mehr zu tun.

[Forumsgast]

Nun, IIRC kann man das. 3 mal TRUE ist dann 3. Das ist in der Tat nicht zielführung, da gebe ich Dir Recht

[Forumsgast]

- Tabelle Drills: ID, Datum, Ort, Typ, Startzeit, Abmeldeschluss
- Tabelle Manning Numbers (jedes Crewmitglied hat eine Besatzungsnummer): ID, ManNo, Department, Duty, Gruppen-ID, LastDrill, MissedDrillsCount, DoNotExempt
- Tabelle Gruppen (jeweils ein Mitglied aus einer Gruppe darf pro Drill max. befreit werden): ID, Typ, Location

- Tabelle DrillExempted: DrillID, ManNoID, Refused

Bei den Menge sehe ich auch keine Probleme, auch weil es datentechnisch nicht mal um die "Lebenszeit" des Schiffes geht (Vielleicht geht es ja beim nächsten Drill sogar unter), sondern eher um die Aufenthaltsdauer eines "man" (gibt's da nicht auch woman?) (im Drill Status=~Ausbildung?). Also pro Drill / Saison wird es häufig Änderungen geben und ein "man" wird vermutlich auch weniger als 367 Jahre dabei sein.

Aber das Datenmodell:
Zum Verständnis: Was soll den DrillExempted:Refused real bedeuten? Hat der 'man' abgelehnt oder wurde er wirklich (z.B. vom Arzt) freigestellt? Oder wurde die Freistellung abgelehnt?
Und wie steht das in Relation zu DoNotExempt?
Und was ist mit dem Anmeldeschluss?
Ich hab mich nicht angemeldet, bin also nicht dabei, wäre eh freigestellt (Magendarm), stehe aber auf DoNotExempt?
Was bedeutet dann "refused"?
Oder muss ich mich sowieso anmelden (automatisch dabei), habs aber vergessen, werde zur Strafe auf DoNotExempt gesetzt, bis ich 20 Drills fehlerfrei abgeleistet habe?

Zu DrillExempted: Die Information steckt momentan in "Refused:True|False".
Sie könnte aber auch "sparsamer" in einem bloßen Aufführen des Datensatzes stehen, also drillid, manid. (Un-)Refused wird in der Existenz (oder nicht Existenz) des Datensatz abgebildet.
Eingetragen = Refused = Exempted = Nicht dabei gewesen
oder umgekehrt
Eingetragen = dabei gewesen

Tellerrand: Wenn die Tabelle zur Teilnahme eines Tages auch andere Informationen abbilden soll, z.B. eine Bewertung des 'Man' im 'Drill', dann muss sie fast zwangsläufig natürlich alle Teilnahmen abbilden und mein Sparvorschlag macht sich negativ bemerkbar. Dann sollte sie aber auch einfach "Teilnahme" oder "ManDrill" oder so heißen und eine Spalte "Exempted" haben plus die anderen Merkmale der Teilnahme.

Dann zu MissedDrillsCount:
Das ist ziemlich redundant, es leitet sich selbst bei meinem sparsamen Vorschlag aus der Anzahl von DrillExempted ab.
Das extra mitzuführen ist meinetwegen legitim, besonders wenn Performance Probleme zu erwarten sind.
Sind sie es nicht, wie hier, kann die DB es problemlos als berechneten Wert bei jedem Zugriff bereitstellen.
Wenn das zu umständlich erscheint (oder zu langsam), muss man geeignete Maßnahmen ergreifen, die sicherstellen, dass diese Zahl nicht den Einträgen in DrillExempted widerspricht. Ansonsten möchte ich nicht die Auswertungen dieser Datenbank verantworten.

Dann ist am Ende noch die Frage, ob die Regel "nur einer pro Gruppe.." in der Datenbank bestehen soll oder nicht. Geht aus dem Modell nicht hervor)
Wenn es in der DB geregelt würde, wäre es "knallhart", man könnte es gar nicht anders eintragen.
Wenn es nur durch die Anwendung "geregelt" wird, wäre es schwächer und wie in der Realität eine Verletzung dieser Regel gehandhabt wird. Kommt drauf an, was gewollt ist.