Warum erstellt er mir keinen Eintrag in diesem Tabel auf der Datenbank?

[uglygeorge08]

Hallo zusammen,

Wieder eine kleine Frage ..

Ausgangslage:

Eine Datenbank mit den beiden Tables "Benutzer" und "Sicherheitsdaten".

(In der Tabelle Benutzer habe ich 2 Keys abgedeckt .. )

Fakten:

Mit meinem PHP-Registrierungs Skript wird in den Tabel "Sicherheitsdaten" das Passwort und die E-Mail Adresse reingeschrieben.

Frage:

Wenn in der Tabelle Sicherheitsdaten ein Eintrag erstellt wird, sollte dann nicht automatisch ein Eintrag in der Tabelle Benutzer erstellt werden?

Diese beiden Tabellen sind ja miteinander vernetzt und wie soll ich nun z.B eine Adresse, welche sich in einer anderen Tabelle befindet, mit den Sicherheitsdaten eines Benutzer verlinken?^^

Zusammengefasst:

Die Tabelle Sicherheitsdaten hat xx Einträge, aber die Tabelle Benutzer bleibt leer, obwohl dort die Sicherheitsdaten_ID übernommen werden soll.

Danke schon im voraus.

Gruss

ugly

Bearbeitet 30. Januar 2011 von uglygeorge08

[robotto7831a]

Von alleine passiert da nichts.

Das muss man schon programmieren.

Frank

[raiserle]

Was du denkst/meinst ist,

referentielle Integrität (r.I.)!

(Wenn ich die MySQL-WB sehe - gehe ich in der Annahme: MySQL!

Du musst dafür aber auch die InnoDB-Engine benutzen!)

Was du willst:

Trigger!

Noch was zu deiner Key-Frage.

r.I. bedeutet ja nicht - lege mir mal die Schlüssel in der anderen Tabelle mit an. Sondern: Prüfe ob es zu einem Konflikt kommt - und machen ein Rollback wenn nötig .

Weiter stellt die r.I. bei einem Insert (DML) ja auch nichts zur Verfügung.

Die einzigen die da ziehen sind: On UPDATE, ON DELETE.

Fragen?

[uglygeorge08]

Was du denkst/meinst ist,

referentielle Integrität (r.I.)!

(Wenn ich die MySQL-WB sehe - gehe ich in der Annahme: MySQL!

Du musst dafür aber auch die InnoDB-Engine benutzen!)

Was du willst:

Trigger!

Noch was zu deiner Key-Frage.

r.I. bedeutet ja nicht - lege mir mal die Schlüssel in der anderen Tabelle mit an. Sondern: Prüfe ob es zu einem Konflikt kommt - und machen ein Rollback wenn nötig .

Weiter stellt die r.I. bei einem Insert (DML) ja auch nichts zur Verfügung.

Die einzigen die da ziehen sind: On UPDATE, ON DELETE.

Fragen?

Danke für deine schnelle Antwort. Wie du schon gesagt hast, verwende ich MySQL und InnoDB.

Das mit dem "Trigger" ist neu für mich, versteh ich bis jetzt noch nicht ganz, werd ich aber demfall noch bissel darüber lesen ..

Als Fazit können wir als nun sagen:

Das ich bei meinem PHP-Registrierungsskript zusätzlich ein SQL-Query erzeugen muss, welcher mir in der Tabelle Benutzer einen Eintrag erstellt?

Mein Ziel ist es:

Anhand einer Benutzer_ID x in der Tabelle Benutzer, alle Daten zu der Personen finden, sei es die E-Mail Adresse / Passwort oder die Adresse, welche ichj ebenfalls mit der Tabelle Benutzer verbinden werde.

Später komme noch Einträge hinzu, welche die Leute erstellen können. Diese sollten natürlich auch einem Benutzer zuweisbar sein ..

Ich stell mir nun die Frage:

Wie kann ich in die Tabelle "Benutzer" den Fremdschlüssen von der Tabelle Sicherheitsdaten übernehmen? ^^

Gruss

ugly

Bearbeitet 30. Januar 2011 von uglygeorge08

[uglygeorge08]

P.S Das mit dem Trigger brauch ich momentan glaub weniger, da es sich im meinem Fall um den ersten Eintrag und kein "Update" handelt. Der Eintrag wird komplett neu erstellt.

sorry für dem double post - aber die editier Zeit war rum ^^

[dr.dimitri]

Dein Datenmodell ist falsch. Der Benutzer hängt nicht an den Sicherheitsdaten sondern umgekehrt.

Also den Verweis zu den Sicherheitsdaten raus aus der Benutzertabelle und statt dessen einen Foreign Key in den Sicherheitsdaten zum Benutzer.

Dann hast auch dieses Henne Ei Problem nicht, denn der User wird zuerst angelegt und dann seine Sicherheitsabfragen - so wie man es auch in der Realität erwarten würde.

Dim

[uglygeorge08]

Dein Datenmodell ist falsch. Der Benutzer hängt nicht an den Sicherheitsdaten sondern umgekehrt.

Also den Verweis zu den Sicherheitsdaten raus aus der Benutzertabelle und statt dessen einen Foreign Key in den Sicherheitsdaten zum Benutzer.

Dann hast auch dieses Henne Ei Problem nicht, denn der User wird zuerst angelegt und dann seine Sicherheitsabfragen - so wie man es auch in der Realität erwarten würde.

Dim

Danke dir - werd ich demfall noch ändern ...

Aber wenn ich zuerst einen Benutzer erstelle, trage ich einfach nix in die Tabelle ein?

Bearbeitet 30. Januar 2011 von uglygeorge08

[uglygeorge08]

Danke dir - werd ich demfall noch ändern ...

Aber wenn ich zuerst einen Benutzer erstelle, trage ich einfach nix in die Tabelle ein?

Ich verstehe die Welt nicht mehr .. :/

Habe nun eine Tabelle "Benutzer". Mit nur einem Attribut, nämlich der Benutzer_ID. Erstell ich dort einen Eintrag, so übernimmt er die ID nicht in die Tabelle "Sicherheitsmassnahmen" und erstellt dort keinen leeren Eintrag mit der jeweiligen Benutzer_ID (als FK).

Ich denke das ich komplett etwas falsches erwarte bzw. ich mein Vorhaben komplett falsche umsetzte? :confused:

sorry für die vielen fragen, aber habe nun heute schon den ganzen tag an diesem Thema verbracht^^

[raiserle]

Datenbankdesign ist das Stichwort für *GOOGLE*.

Dazu noch Normalisierung als zweites Stichwort für *GOOGLE*.

+ 1:1 , 1:n, n:m

Damit sollten erst einmal die Grundlagen vorhanden sein. Alles Andere kommt dann mit Übungen.

Es bringt nix, wenn wir uns jetzt hier ein Bein ausreissen - und du die Grundlagen nicht inne hast.

Tip:

Dein jetziges Problem hat was mit Normalisierung zu tun! Welche Daten wohin und warum?

OT

Ähm wie war das nochmal mit den Atomen

lG

[raiserle]

Da ich eh grad lange Weile habe...

so ein paar kleine Sachen

1:1 Beziehungen machen nicht wirklich Sinn - in getrennte Tabellen zu speichern.

n:m Beziehungen kann man nicht so einfach Übernehmen (Chen ist zwar schön.. aber geht halt nicht) man muss jeweils in eine 1:n:1 auflösen. Kann man schön bei der MySQL-WB nachvollziehen.

In deinem konkreten Fall:

Der Benutzer = Relation 1

Die Sicherheitsfargen = Relation 2

Die Fragen = Tupel von Realtion 2

Die Antwort = Genau eine von einem Benutzer

Daraus ergibt sich follgendes:

DB-Design

Bearbeitet 30. Januar 2011 von raiserle
db-design.. naja

[MartinSt]

1:1 Beziehungen machen nicht wirklich Sinn - in getrennte Tabellen zu speichern.

Wenn man in der Praxis schonmal "breite" Tabellen mit Dutzenden Attributen gesehen hat, die sich dazu noch in der Fachlogik prima unterteilen lassen, dann würde ich dieser Aussage widersprechen.

[raiserle]

Aber was hast du am Ende davon. Ausser 2 Tabellen

Gut, wenn du immer MIT * abfragst....

lG

[MartinSt]

Für mich spiegeln die Tabellen immer weitgehend das BO-Modell wieder und deswegen trenne ich das.

[uglygeorge08]

Da ich eh grad lange Weile habe...

so ein paar kleine Sachen

1:1 Beziehungen machen nicht wirklich Sinn - in getrennte Tabellen zu speichern.

n:m Beziehungen kann man nicht so einfach Übernehmen (Chen ist zwar schön.. aber geht halt nicht) man muss jeweils in eine 1:n:1 auflösen. Kann man schön bei der MySQL-WB nachvollziehen.

In deinem konkreten Fall:

Der Benutzer = Relation 1

Die Sicherheitsfargen = Relation 2

Die Fragen = Tupel von Realtion 2

Die Antwort = Genau eine von einem Benutzer

Daraus ergibt sich follgendes:

DB-Design

Danke aber leider hast du überhaupt nichts von meinen Fragen beantwortet. Es geht hier nicht um das Datenbankbankdesign, sondern eher um eine simple frage: "Warum beim erstellen der Benutzer_ID", diese nicht in die Tabelle "Sicherheitsmassnahmen" übernommen bzw. eingetragen wird.

Bsp:

Tabelle Benutzer:

BenutzerID 1

Tabelle Sicherheitsdaten

Sicherheits_ID 1 | Passwort: test | Benutzername: test | BenutzerID (leer)

Klar könnte ich das ganze zusammenfassen, habe ich mir auch schon überlegt. Das ändert aber nichts an der Tatsache, dass es doch irgendwie umsetzbar sein sollte? :/

Diese 1 müsste doch auch in der Tabelle Sicherheitsdaten stehen?

Naja ... werd mich so oder so nochmals dami befassen, sonst komme ich hier glaubs nicht mehr weiter.

Bearbeitet 30. Januar 2011 von uglygeorge08

[raiserle]

Dies hatte ich dir aber schon beantwortet - und zwar HIER

Trigger!

Du kannst nicht auf ein INSERT reagieren, wenn du eigentlich was anderes meinst. (CONSTRAINT - FK [ForeignKey]).

Die DML sieht hier nur bei einem *UPDATE/DELETE* etwas vor - und zwar

a) den FK NULL werden lassen

den FK so lassen wie er ist

c) die Tupel löschen - mit dem betroffenen FK

d) abweisen von DELETE/UPDATE

Wenn du deine Frage explizit stellen würdest, käme die Antwort:

mysql_insert_id

Bearbeitet 30. Januar 2011 von raiserle
Nachtrag mysql_INSERT_ID

[uglygeorge08]

Dies hatte ich dir aber schon beantwortet - und zwar HIER

Trigger!

Du kannst nicht auf ein INSERT reagieren, wenn du eigentlich was anderes meinst. (CONSTRAINT - FK [ForeignKey]).

Die DML sieht hier nur bei einem *UPDATE/DELETE* etwas vor - und zwar

a) den FK NULL werden lassen

den FK so lassen wie er ist

c) die Tupel löschen - mit dem betroffenen FK

d) abweisen von DELETE/UPDATE

Wenn du deine Frage explizit stellen würdest, käme die Antwort:

mysql_insert_id

danke dir - der link sieht sehr gut aus.

hast mir sehr weitergeholfen, hätte aber nicht gedacht, dass man hierfür sogar einen Trigger verwenden muss ... :confused:

Gruss

ugly

[dr.dimitri]

Im allgemeinen verwendet man dazu auch keinen Trigger, sondern trägt die Daten die man haben möchte selbst ein. Wenn ich einen leeren Eintrag möchte, dann lege ich ihn an - dazu braucht man keinen Trigger.

Über mysql_insert_id() bekommst Du die gerade vergebene ID der Tabelle und kannst sie verwenden um die Sicherheitsdaten zu befüllt.

Dazu muss man keinen Trigger erstellen und dort irgendwelche Logik verstecken.

Dim

[raiserle]

Der Dr. hats dir gesagt - man muss keinen Trigger verwenden. ABER man kann.

Und es zielte genau auf deine Frage ab, wie bekomme ich nen EINTRAG in Tabelle B, wenn ich was in Tabelle A schreibe - ohne weiteren PROGRAMMCODE (php: angenommen). *trivial* TRIGGER!

Denn das war deine Frage im ersten Post

[uglygeorge08]

Im allgemeinen verwendet man dazu auch keinen Trigger, sondern trägt die Daten die man haben möchte selbst ein. Wenn ich einen leeren Eintrag möchte, dann lege ich ihn an - dazu braucht man keinen Trigger.

Über mysql_insert_id() bekommst Du die gerade vergebene ID der Tabelle und kannst sie verwenden um die Sicherheitsdaten zu befüllt.

Dazu muss man keinen Trigger erstellen und dort irgendwelche Logik verstecken.

Dim

Genau diese Funktion ermöglicht mir schlussendlich das vernezten der beiden Tabellen. Das habe ich gesucht ..

Dann wird die ID 1 von der Tabelle Benutzer genommen und anschliessend in die Tabelle Sicherheitsdaten bzw. dem Attribut SicherheitsdatenID eingetragen.

Grosses Kompliment an dieses Forum - wirklich grosses Kino was ihr hier liefert ..

Werds heute bzw- morgen Abend gleich mal in PHP umsetzen.

gruss

ugly

Der Dr. hats dir gesagt - man muss keinen Trigger verwenden. ABER man kann.

Und es zielte genau auf deine Frage ab, wie bekomme ich nen EINTRAG in Tabelle B, wenn ich was in Tabelle A schreibe - ohne weiteren PROGRAMMCODE (php: angenommen). *trivial* TRIGGER!

Denn das war deine Frage im ersten Post

hehe okey ..

Bearbeitet 31. Januar 2011 von uglygeorge08