tabellenID mit php ermitteln

[Johann]

Hallo,

habe eine mysql db mit verschiedenen Tabellen, die ich über ein HTML-Formular und PHP befüllen möchte. Das Formular enthält Pflichtangaben als auch optionale Angaben.
In der Pflichttabelle habe ich die ID auf autoincrement gesetzt. Die Pflichttabelle hat als Fremdschlüssel die ID der optionalen Tabelle. Da aber nicht bei jedem abgesendeten Formular optionale Angaben vorhanden sind können Leereinträge in der Pflichtentabelle entstehen.
Weiterhin weiß ich nicht, wie ich die passende ID für die optionale Tabelle ermitterln kann.

Hoffe es ist verständlich und jemand hat eine (einfache) Lösung.

Johann

[Rolf]

Hallo Johann,

Hoffe es ist verständlich und jemand hat eine (einfache) Lösung.

Lösung: JA,
einfach: keine Ahnung (für mich auch JA)

Also:
Die Tabelle(n) mit den optionalen Eigenschaften haben ja auch eine ID, die,
so hoffe ich, ebenfalls auf auto_increment steht. Sinnvollerweise werden zuerst
die optionalen Daten gespeichert. Danach ermittelt man mit mysql_insert_id die
dazugehörige ID und kann dann entspannt die Hauptdaten speichern.
HTH

m.b.G. Rolf

[Johann]

Hallo Rolf & Rouven,

einfach: keine Ahnung (für mich auch JA)

für mich jetzt auch - super Sache.

bist du sicher, dass du den Fremdschlüssel sorum wählen willst und nicht anders herum?

Ich denke, wenn ich das mache sollte mein konzeptioneller Fehler soweit aus der Welt sein.

Vielen Dank für eure Hilfe, jetzt kanns endlich weiter gehen.

Johann

[Rouven]

Hello,

In der Pflichttabelle habe ich die ID auf autoincrement gesetzt. Die Pflichttabelle hat als Fremdschlüssel die ID der optionalen Tabelle.

ohne einen Schimmer zu haben, was dein Datenmodell abbilden soll - bist du sicher, dass du den Fremdschlüssel sorum wählen willst und nicht anders herum?

Da aber nicht bei jedem abgesendeten Formular optionale Angaben vorhanden sind können Leereinträge in der Pflichtentabelle entstehen.

das halte ich für einen konzeptionellen Fehler - erkenne diese Situation und unternimm etwas dagegen.

MfG
Rouven

[Rolf]

Hallo Du konzeptioneller Fehler,

bevor Du hier Sprüche klopfst, stell Dir mal ein einfaches Beispiel vor.

In der Haupttabelle werden persönliche Daten hinterlegt, hat jeder, klar.
In der Nebentabelle werden Fahrzeuge mit nennenswertem Zeitwert gespeichert.
Da dürfte es bei den meisten eher schlecht aussehen, gell ... ;-)

Wie ich darauf komme, ganz einfach, meine neue Versicherung wollte nur
wissen, ob das zu versicherte Fahrzeug über oder unter 50T€ wert ist.
Alles was darunter ist, läuft unter Peanuts ... ;-)

m.b.G. Rolf

[Auge]

Hallo

Hallo Du konzeptioneller Fehler,

bevor Du hier Sprüche klopfst, stell Dir mal ein einfaches Beispiel vor.

In der Haupttabelle werden persönliche Daten hinterlegt, hat jeder, klar.
In der Nebentabelle werden Fahrzeuge mit nennenswertem Zeitwert gespeichert.
Da dürfte es bei den meisten eher schlecht aussehen, gell ... ;-)

Und? Es gibt Daten, die sind zwingend und es gibt Daten die sind optional. Was lässt dich vermuten, dass es sinnvoll ist, erst die optionalen Daten zu speichern und mit der daraus resultierenden ID die zwingend vorausgesetzten Daten *nach* diesem Vorgang abzulegen?

Wäre es nicht sinnvoll, erst alle Zwangsdaten zu speichern und dann _im_Bedarfsfall_ mit der ID des Datensatzes der Zwangsdaten, die *immer* angelegt werden, die eventuell zusätzlich erhobenen Daten zu speichern.

Davon ab, Was hat das mit deinem Beispiel des Zeitwertes eines Fahrzeugs zu tun?

Tschö, Auge

[Auge]

Hallo

Davon ab, ...

... Was hat dein Beispiel des Zeitwertes eines Fahrzeugs mit dem Abspeichern von Daten im jetzt diskutierten Tabellenmodell zu tun?

Tschö, Auge

[Rolf]

Hallo Auge,

... Was hat dein Beispiel des Zeitwertes eines Fahrzeugs mit dem
Abspeichern von Daten im jetzt diskutierten Tabellenmodell zu tun?

ganz einfach,

• die Daten des Versicherungsnehmers sind zwingend - Haupttabelle
• die Daten des hochwertigen Fahrzeuges sind optional - Nebentabelle

Wer seinen "Alten" versichern lässt, hat keine ID in der Nebentabelle.

m.b.G. Rolf

[Rouven]

Hello,

• die Daten des Versicherungsnehmers sind zwingend - Haupttabelle
• die Daten des hochwertigen Fahrzeuges sind optional - Nebentabelle

und wie viele Autos speicherst du mit diesem System pro Versicherungsnehmer? Eines.
Deswegen meine Aussage, dass ich die Modellierung falsch herum vermute, bei einer 1:n-Beziehung gehört der Fremdschlüssel auf die n-Seite, Haupttabelle klingt für mich nach einer 1-Seite. Ich bin allerdings durchaus bereit zu akzeptieren, wenn es sich hier um eine 1:1-Beziehung handelt, wobei, dann verstehe ich nicht, warum überhaupt eine Aufteilung vorgenommen wird.

MfG
Rouven

[Rolf]

Hallo Rouven,

wenn es sich hier um eine 1:1-Beziehung handelt,

davon bin ich ausgegangen

warum überhaupt eine Aufteilung vorgenommen wird.

kannst Du Dich noch an xBase erinnern?
Da gab es auch eine Aufteilung im gleichen Datensatz.
Die Memofelder waren in einer seperaten Datei, so wurde die DB performanter.

m.b.G. Rolf

[Rolf]

Hai,

in einem Kunstshop gibt es die Tabellen "Werke", "Künstler" und "Techniken".
Jedes Werk hat einen Künstler und eine Technik, aber jeder Künstler hat viele Werke und zu jeder Technik gehören auch viele Arbeiten.

Hier muss, bevor das Werk eingetragen werden kann, die Künstler-ID und die
Technik-ID ermittelt werden um sie in die Haupttabelle "Werke" zu notieren.

m.b.G. Rolf

[Rouven]

Hello,

Hier muss, bevor das Werk eingetragen werden kann, die Künstler-ID und die
Technik-ID ermittelt werden um sie in die Haupttabelle "Werke" zu notieren.

ich würde nie anzweifeln, dass es Dinge gibt, die da sein müssen, bevor andere Dinge angelegt werden können. Das liegt in der Natur der relationalen Welt.

MfG
Rouven

[Rouven]

Hello,

Die Memofelder waren in einer seperaten Datei, so wurde die DB performanter.

um soetwas wie die Verwaltung von LOBs hat sich IMHO das DBMS zu kümmern, nicht ich in meiner Datenbankverwaltung. Man findet sicherlich eine Begründung für eine 1:1 Beziehung, sei es Vererbung oder sonst etwas, aber erstmal macht es das Datenmodell künstlich kompliziert.

MfG
Rouven

[Auge]

Hallo

... Was hat dein Beispiel des Zeitwertes eines Fahrzeugs mit dem
Abspeichern von Daten im jetzt diskutierten Tabellenmodell zu tun?
ganz einfach,

• die Daten des Versicherungsnehmers sind zwingend - Haupttabelle
• die Daten des hochwertigen Fahrzeuges sind optional - Nebentabelle

Wer seinen "Alten" versichern lässt, hat keine ID in der Nebentabelle.

Nun wäre es mir fremd, dass ein Versicherungsunternehmen auf die Daten meines alten Wagens verzichtet, wenn sie ihn schon versichert, aber bitteschön.

Bleibt meine Frage: Warum denkst du (und so interpretiere ich deine Antwort an Rouven) dass zuerst die optionalen Daten gespeichert werden sollten und erst danach, mit der ID der optionalen Daten, die zwingend anzugebenden Daten? *Das* ist hier nämlich die von Rouven aufgeworfene Frage gewesen (richtiges Datenmodell?).

Schon die Tatsache, dass ich mehrere Wagen haben könnte, der Trend geht ja schließlich, Jahre nachdem ein Trend zum Zweitbuch zu beobachten war, auch zum Zweitrechner, impliziert eine 1-zu-N-Beziehung, womit der Fremdschlüssel logischerweise bei N (die (eventuell) mehreren Autos) liegen sollte und auf 1 (die Daten des einen Fahrzeughalters; mithin die zwingenden Daten) verweist.

Daraus folgert, dass (praktisch gesehen) erst die Daten zum Fahrzeughalter zu speichern sind, denn diese sind es, die eindeutig sind, und danach, mit der dabei/danach ermittelten ID des betreffenden Datensatzes, die Daten zum Fahrzeug, die mit dem Fremdschlüssel auf den Fahrzeughalter verweisen (womit datenmodellmäßig gesichert wäre, dass ich beliebig viele Fahrzeuge haben kann, selbst, wenn ich mir die garnicht leisten (Ich sollte mal bei meiner Bank nachfragen, ob ich nicht auch mal ungestraft ein bisschen Geld verbrennen darf.)).

Tschö, Auge

[Vinzenz Mai]

Hallo Rolf,

Hallo Du konzeptioneller Fehler,
bevor Du hier Sprüche klopfst, stell Dir mal ein einfaches Beispiel vor.

Rouven hat es wunderbar auf den Punkt gebracht - und keine Sprüche geklopft.

Freundliche Grüße

Vinzenz