SQL SQL Befehle triggern, Abhängigkeiten

[nik_]

Hi,

habe nen Datenbankmodell vor mir liegen und mittels paar Tricks die DB schon auf nem lokalen virtuellen Server liegen. Das DB-modell ist schon was größer und beinhaltet mehrere Abhängigkeiten. Und da brauche ich Hilfe.

Ich werde das DB-Model in den Anhang hängen, damit ihr euch einen Überblick machen könnt. Mir geht es dann um folgendes: Ich habe verschiedene Mustertrainingspläne. Und kann dann einem Mitglied einen Musterplan zuordnen. Die Daten (Übungen und Wiederholungen) müssen dann in den konkreten Plan des Mitglieds eingetragen werden.
Und genau hier hängts bei mir. Wenn ich ein neues Mitglied anlege und einen Musterplan zuweise, dann muss ein Befehl getriggert werden, so dass die entsprechenden Daten eben diesem konkreten Plan zugewiesen werden.

Dann brauche ich nen tipp wie ich jedes mal nen neuen aktuell_trainierten plan anlegen kann mit bezug zum konkreten plan (müsste ja dann die id vom konkreten plan abfragen und dann jedes mal die entsprechenden *.php datei auf dem server aufrufen [android app entwicklung]. das sollte allerdings net so schwer werden.

brauche halt primär hilfe, beim 1. punkt. wie trigger ich da den befehl korrekt, wenn ich dem mitglied X nen msuterplan Y zuordne, sodass das der konkrete plan entsteht.

 

[ella_one]

Hallo nik_,

So was wird programmiert, da ist nichts mit Triggern! Besuch doch einmal eine SQL Schulung des von Dir verwendeten DBMS. Das Datenmodell ist durchaus gewöhnungsbedürftig. Womit wurde das denn verbrochen? Ich kenne u.a. die DBMS IBM DB2 und MS SQL Server – dort werden normierte Datenmodelle generiert, wobei bei IBM DB2 die Eclipse Workbench und bei MS SQL Server das Management Interface zum Einsatz kommen.

Viel Erfolg

 

[nik_]

das ist nen normiertes db modell aus dem sql data developer von oracle. das ding hat normalform. außerdem wie soll ich als student ne sql schulung besuchen? wir hatten zwar datenbanken aber sowas komplexes nun auch nicht.

da ich eh noch ne einfache web oberfläche machen wollte/muss, sollte es doch reichen, dass wenn ich dort 1 person nen musterplan zuweise, z.B. ne php skript aufzurufen was auf die db zugreift und die sachen in die neue tabelle kopiert oder habe ich da nen denkfehler?

 

[mambokurt]

Eben das meint er mit programmiert werden.
Ein Trigger ist was Datenbankspezifisches, du legst quasi in der Datenbank eine Funktion an und lässt die immer ausführen, wenn ein bestimmtes Feld angefasst oder erstellt wird.

In der Richtung gibt es zwei Denkschulen und vieles dazwischen:
- die einen wollen möglichst wenig über die Datenbank machen, das hat den Vorteil dass man beim Programmieren nicht viel verbocken kann. Sprich wenn der Datenbankfuzzi seine Arbeit ordentlich macht, braucht der Programmierfuzzi sich nicht groß kümmern und kann sich um andere Sachen kümmern.
-die anderen wollen möglichst viel über die Programmiersprache regeln, das hat den Vorteil, dass man mehrere DBMS anbinden kann.

Es gibt einen kleinsten gemeinsamen Nenner (naja, sollte es geben): Trigger auf Fremdschlüssel bei Delete/Update usw. Heißt: ich lösche aus Tabelle X Datensatz 1, also wird aus Tabelle Y auch Datensatz 1 gelöscht. Selbst das ist aber eher der Idealfall als die Realität, wenn du eine kleine Firma hast die auf 4 Datenbanken programmiert, kann selbst das per Hand über Programmierung erledigt werden.

Zu deiner Frage: ich glaube du denkst da falsch. Du hast ja schon gesagt, dass du über PHP deine Person anlegst. Nun musst du aber, um deiner Person einen konkreten Plan zuzuordnen, zwingend einen Musterplan angeben. Musterpläne gibts mehrere, die kannst du nicht raten. Folglich ist die Entscheidung _welcher_ Musterplan da nun zugeordnet wird also eine Entscheidung die von außen kommt, eine Entscheidung des Users sozusagen. Du legst also _nicht_ nur die Person an, du musst in einem Zug mit der Anlage der Person übers PHP/Webinterface/Whatever auch sagen, welchen Musterplan die Person nun erstmal bekommt. Das machst du zB über ein Selectfeld oder wenn es ganz wild wird über einen Wizard, der beim Anlegen ein paar Fragen stellt, um den richtigen Musterplan zu ermitteln(wie gesagt, _bevor_ die Person überhaupt angelegt wird). hast du dann den richtigen Musterplan ermittelt, ist der Rest EasyPeasy: du legst ganz normal deine Person an, legst direkt danach den konkten Plan an und schreibst da die ID deiner Person und des Musterplanes rein. Das ist also keine Raketenwissenschaft, einfach nur eine Frage von 'ist das jetzt eine Info von außen oder kann ich die selbst ermitteln?'.

Da das eine Übungsaufgabe sein soll, gehe ich jetzt mal nicht auf die diversen offenen Punkte im Datenmodell ein, kann man so machen, aber dann ist es halt doof

 

[nik_]

ist keine hausaufgabe sondern ne app die ich für nen projekt mache. habe bis dato wenig mit db zu tun gehabt.

die musterpläne sind bekannt (da vorgegeben). diese sind einfache standard trainingspläne zum einstieg oder fortgeschritten. es gibt auch einen leeren musterplan, sodass alle übungen frei gewählt werden können (hier wird dann erst nach anlegem des users durch ihn festgelegt welche übungen er trainieren möchte).

im endeffekt habe ich mir das so gedacht.
- user kriegt fragebogen und füllt ihn aus
- user anlegen und musterplan nach fragebogen zuordnen // oder user neuen plan zuordnen
- konkreten plan mit übungen und wiederholungen des musterplans anlegen

kann das db modell auch abändern (war halt mit meinem d prof zusammen entwickelt). gibts da schwierigkeiten?

 

[mambokurt]

user anlegen und musterplan nach fragebogen zuordnen // oder user neuen plan zuordnen

-> du ordnest nicht dem Nutzer einen Nutzerplan zu, sondern einen konkreten. Du findest raus was für ein Musterplan passt, dann wird ein konkreter Plan dazu mit dem Musterplan und dem User erstellt.

Das mag sich wie Haarspalterei anhören, aber das muss klar sein und an solchen Stellen musst du selbst im Kopf und im Ausdruck extrem penibel werden, sowas fährt Projekte gegen die Wand wenn es übel läuft und schlecht kommuniziert wird.


Dein Modell kann man schon so nehmen, in der Praxis wird dir dann auffallen was fehlt. Die Trainer sind zb etwas stiefmütterlich umgesetzt, die werden wahrscheinlich noch etwas Zuwendung brauchen (wenn du jetzt sagst du willst nur Kunden verwalten und denen Trainingspläne geben ist das legitim, in der Praxis kann ein Trainer aber X Kunden zur selben Zeit unterrichten), das selbe gilt für die Stammdaten allgemein. Fehlermeldung/Übung Fehler ist Imho an der Praxis vorbei, ich glaube nicht dass sich ein Fitnesstrainer jede Stunde hinstellt und die Fehler eintippt, die die Kunden gemacht haben. Generell sehe ich etstmal das größte Problem in den Ressourcen. Du hast nur X Trainer und Y Geräte(die bei dir noch gar nicht im Modell sind) wenn du also 200 Leuten Montag und Donnerstag um 12:00 Kardio aufdrückst, sind die Trainer völlig überlastet und 150 Leute stehen am Laufband schlange. Kommt natürlich drauf an, wie weit man das jetzt treiben will...

Aber wie gesagt, an deinem grundsätzlichen Vorgehen ändert das alles erstmal nichts, und so eine Datenbank ist nicht in Stein gemeißelt. Das merkst du dann spätestens beim Entwickeln wenn etwas fehlt Das Grundkonzept mit Musterplan, konkretem Plan und dem User/den Wochentagen wirkt auf jeden Fall halbwegs schlüssig.

 

[nik_]

es gibt keine uhrzeit. einen trainer weise ich keinem kunden zu. der kunde kriegt die "app" für das studio und kann selber fehlermeldungen abschicken die dann beim trainer, besitzer ankommen. ob es jetzt ne einführung durch trainer gibt oder nicht, kann man ja "separat" machen.

der wochentag wird einem plan zugeordnet, so dass gesagt werden kann, wie oft jemand trainieren gehen kann (z.b. 3mal die woche Mo, Mi, Fr).

Im Modell werden die Geräte die du vermisst mit Übung bezeichnet, da es auch Übungen gibt die keine Geräte benötigen.

theoretisch kann ich auch Person durch Kunde ersetzen, habe ich aber aktuell nicht, da trainer auch kunde sein kann.

 

[mambokurt]

Na dann ist doch alles tutti