Prinzipielle Frage zum Arbeiten mit nichtredundanten Datenbanken

[Melvin Cowznofski]

Hallo,

ich habe eine prinzipielle Frage zum Arbeiten mit nichtredundanten Datenbanken. Gegeben sind die Tabellen 'Orte' und 'Mitglieder':

Tabelle 'Orte':

ID | Ort                            | Postleitzahl
---------------------------------------------------
 1  | Kumelbach                      | 12345
 2  | Brezenstein                    | 24573
 3  | Kotzenbach                     | 22343
 4  | Unterlibgenstein im Lummerland | 36221

Tabelle 'Mitglieder':

ID | Vorname    | Familienname | Ort
------------------------------------
1  | Hans-Peter | Meier        | 2
2  | Maria      | Duttlinger   | 1
3  | Georg      | Rothaar      | 1
4  | Martin     | Pimmelstein  | 3
5  | Andrea     | Huber        | 2

Wenn ich jetzt ein Formular erstelle, bei dem ein neues Mitglied in der DB angelegt werden soll (unter der vereinfachten Annahme, dass der Wohnort des neuen Mitglieds schon in der Tabelle Orte steht!), dann würde _ich_ das so tun:

Aus der Tabelle 'Orte' die ausgeschriebenen Ortsnamen auslesen und damit im Formular eine Auswahlliste erstellen. (1. DB Interaktion) Dabei ist der erste Punkt der Auswahlliste ein "Bitte Ort wählen". Damit kontrolliere ich bei der Eingabevalidierung, ob auch wirklich ein Ort ausgewählt worden ist.

Wurde eine Name eingegeben und ein Ort ausgewählt, suche ich mir in der Tabelle 'Orte' den ausgewählten Ort und lasse mir die dazugehörende ID ausgeben. (2. DB Interaktion).

Dann speichere ich den Namen des neuen Mitglieds samt der soeben herausgefundenen Orts-ID in der Tabelle 'Mitglieder'. (3. DB Interaktion)

Ich würde jetzt gerne wissen, ob man die Schritte 2 und 3 zusammenfassen kann zu einer einzigen DB Interaktion (und wenn ja, wie dann die Query aussehen würde) oder ob das beschriebene Procedere usus ist.

Mit lieben Grüßen

Melvin Cowznofski

[Klawischnigg]

Hi there,

Ich würde jetzt gerne wissen, ob man die Schritte 2 und 3 zusammenfassen kann zu einer einzigen DB Interaktion (und wenn ja, wie dann die Query aussehen würde) oder ob das beschriebene Procedere usus ist.

Ich würde eher in Schritt 1 die ID mitauslesen und irgendwie mit dem Ort so verbinden, daß Schritt 2 entfallen kann...

[Melvin Cowznofski]

Hallo Klawischnigg!

Ich würde eher in Schritt 1 die ID mitauslesen und irgendwie mit dem Ort so verbinden, daß Schritt 2 entfallen kann...

Aber wo soll diese Information einstweilen gespeichert werden? Die Seite ruft als Affenformular sich selbst zur Validierung und Weiterverarbeitung auf. Da käme dann nur der Weg mit Session oder Cookie in Frage. Das wäre ja _noch_ komplizierter.

Und die ID mit dem Ort im Auswahlfeld anzuzeigen und bei der Weiterverarbeitung zu extrahieren gefällt mir optisch nicht, da ich (in diesem Beispielfall) nur die Orte in der Auswahlliste stehen haben möchte.

Mit lieben Grüßen

Melvin Cowznofski

[MudGuard]

Hi,

Und die ID mit dem Ort im Auswahlfeld anzuzeigen und bei der Weiterverarbeitung zu extrahieren gefällt mir optisch nicht, da ich (in diesem Beispielfall) nur die Orte in der Auswahlliste stehen haben möchte.

<input type="hidden">

Das ist aber manipulierbar.

cu,
Andreas

[bubble]

Und die ID mit dem Ort im Auswahlfeld anzuzeigen und bei der Weiterverarbeitung zu extrahieren gefällt mir optisch nicht, da ich (in diesem Beispielfall) nur die Orte in der Auswahlliste stehen haben möchte.

<select name="ort">  
    <option value="5">Berlin</value>  
</select>

Und schon hast du eine Optik wieder ins reine gebracht.

MfG
bubble

[Melvin Cowznofski]

Hallo bubble!

<select name="ort">

<option value="5">Berlin</value>
</select>

  
(Du meinst sicher </option> statt </value>?!)  
  
Natürlich, Du hast Recht, ich sah den Wald vor lazter Bäumen nicht! Dankeschön!  
  

> Und schon hast du eine Optik wieder ins reine gebracht.  
  
Stimmt! :)  
  
Mit lieben Grüßen  
  
Melvin Cowznofski  

-- 
  
![Melvin Cowznofski](http://webstuff.at-web.cc/public/selfhtml/profile/melvin_cowznofski.png)  
  
What – me worry?

[bubble]

<select name="ort">

<option value="5">Berlin</value>
</select>

>   
> (Du meinst sicher </option> statt </value>?!)  

Ja, na klar, ich hab halt den Wald gesehen und nicht mehr auf den einzelnen Baum geachtet ;)  
  
MfG  
bubble

-- 
If "god" had intended us to drink beer, he would have given us stomachs. - David Daye

[Kurt]

Aber wo soll diese Information einstweilen gespeichert werden? Die Seite ruft als Affenformular sich selbst zur Validierung und Weiterverarbeitung auf. Da käme dann nur der Weg mit Session oder Cookie in Frage. Das wäre ja _noch_ komplizierter.

Aus selfhtml:

  
<form action="select.htm">  
  <p>Ihre Pizza-Bestellung:</p>  
  <p>  
    <select name="Pizza" size="5"  
        onchange="alert(this.form.Pizza.options[this.form.Pizza.selectedIndex].value)">  
      <option value="P101">Pizza Napoli</option>  
      <option value="P102">Pizza Funghi</option>  
      <option value="P103">Pizza Mare</option>  
      <option value="P104">Pizza Tonno</option>  
      <option value="P105">Pizza Mexicana</option>  
      <option value="P106">Pizza Regina</option>  
      <option value="P107">Pizza de la Casa</option>  
      <option value="P108">Pizza Calzone</option>  
      <option value="P109">Pizza con tutti</option>  
    </select>  
  </p>  
</form>  
  
Kurt  

[Klawischnigg]

Hi there,

Aber wo soll diese Information einstweilen gespeichert werden? Die Seite ruft als Affenformular sich selbst zur Validierung und Weiterverarbeitung auf. Da käme dann nur der Weg mit Session oder Cookie in Frage. Das wäre ja _noch_ komplizierter.

Da gibts mehrere Möglichkeiten. Eine besteht wie schon beschrieben darin, als option-Value die ID zu nehmen und den Ort einfach angezeigt lassen. Wenn Du den Ort nach der Auswahl noch brauchts, dann kannst Du den Ort ja NACH der ID an den String anhängen und nachher extrahieren, ich seh' da absolut kein Problem, ich denke im Gegenteil, ich würde das so lösen.
Eine andere Möglichkeit wäre ein Array, das Du serialisiert weitergibst; eine dritte Möglichkeit wären hidden-Inputfelder (mit der ebenfalls bereits beschriebenen Möglichkeit der Manipulation; dem könnte man aber entgehen, wenn man die ID irgendwie verschlüsselt oder mit  Prüfsumme versieht). Wahrscheinlich gibts noch ein paar Möglichkeiten, die allesamt besser wären als ein weiterer Zugriff auf die DB; vor allem hast Du da ja das ohnehin das Problem, daß Du bei gleichen Ortsnamen schon anstehst, wenn Du wirklich nur den Ortsnamen übergibst...

[dedlfix]

Tach!

Eine andere Möglichkeit wäre ein Array, das Du serialisiert weitergibst; eine dritte Möglichkeit wären hidden-Inputfelder (mit der ebenfalls bereits beschriebenen Möglichkeit der Manipulation; dem könnte man aber entgehen, wenn man die ID irgendwie verschlüsselt oder mit  Prüfsumme versieht).

Wo ist denn da das Problem, einen sowieso vom Nutzer gewählten/eingegebenen/änderbaren Wert über ein Hidden-Feld mitzuschleppen? Wenn er eine nicht existente ID übergeben will, kann er das bereits im ersten Schritt machen. Eine Manipulationsverhinderung braucht man nur für Werte, die nicht vom Benutzer beeinflusst werden sollen. Die sollte man nach Möglichkeit gleich gar nicht erst an den Client senden. Sessions sind heutzutage problemlos verfügbar.

dedlfix.

[Kurt]

Hi,

Aus der Tabelle 'Orte' die ausgeschriebenen Ortsnamen auslesen und damit im Formular eine Auswahlliste erstellen. (1. DB Interaktion) Dabei ist der erste Punkt der Auswahlliste ein "Bitte Ort wählen". Damit kontrolliere ich bei der Eingabevalidierung, ob auch wirklich ein Ort ausgewählt worden ist.

Das reicht so aber nicht aus. Denn anscheinend gehst Du davon aus, daß wirklich ein Ort gewählt wurde, wenn Dein "Passus" nicht in den Request-Daten erscheint.

Ich würde jetzt gerne wissen, ob man die Schritte 2 und 3 zusammenfassen kann zu einer einzigen DB Interaktion (und wenn ja, wie dann die Query aussehen würde) oder ob das beschriebene Procedere usus ist.

Per Subselect geht das.

Kurt

[MudGuard]

Hi,

Aus der Tabelle 'Orte' die ausgeschriebenen Ortsnamen auslesen und damit im Formular eine Auswahlliste erstellen.

Ortsnamen sind nicht eindeutig.
Und manche Orte, die es nur einmal gibt, haben dennoch mehrere PLZ (Stuttgart z.B.).

Wenn, dann muß die Kombination aus PLZ und Ortsnamen ausgewählt werden.

Ob eine Auswahlliste dafür geeignet ist, wage ich anzuzweifeln. Wenn nur Zustelladressen berücksichtigt werden, gibt es ca. 20000 Kombinationen.

cu,
Andreas

[dedlfix]

Tach!

ich habe eine prinzipielle Frage zum Arbeiten mit nichtredundanten Datenbanken. Gegeben sind die Tabellen 'Orte' und 'Mitglieder':

Und da haben wir wieder ein Problem, bei dem man einerseits nur direkt auf die Frage antworten könnte, andererseits aber die Frage nach dem Warum stellen kann. Denn das was du da vorhast, scheint mir nicht sonderlich sinnvoll, ohne dass ich deine Begründung für die Aufteilung kenne. Man muss nämlich nicht auf Teufel-komm-raus normalisieren.

Geht es also darum, Adressen zu verwalten? Dann würde man in der Regel die Orte als Teil der Adresse sehen und sie nicht auslagern. Besonders nicht in Kombination mit den Postleitzahlen, denn wie schon gesagt, gibt es Orte mit mehreren PLZ. Und es gibt auch PLZ mit mehreren Orten (von Postfachadressen ganz zu schweigen). Das Kriterium PLZ ist an und für sich ein wenig interessantes Datum. Es ist einfach nur Teil der Adresse. - Und nun kommen die Einwände, dass man sein Vertriebsgebiet nach Postleitzahlen aufgeteilt hat und dergleichen. Nunja, die PLZ sind ein Ordnungskriterium der Post. Hat man denn für seine Vertriebsstruktur dieselbe Struktur wie bei der Post? Und strukturiert man sich selbst auch um, wenn die Post Änderungen vornimmt? Wie auch immer, ich schweife ab.

Geht es andererseits darum, dass den Orten eine besondere Bedeutung begemessen ist? Vielleicht sind das ja die Vertriebsgebietsgrenzen. Dann wäre eine separate Orte-Tabelle sinnvoll. Aber eigentlich würde man das dann Vertriebsgebiete oder ähnlich nennen, damit die Bedeutung klarer wird.

dedlfix.

[Linuchs]

Hallo dedlfix,

Nunja, die PLZ sind ein Ordnungskriterium der Post. Hat man denn für seine Vertriebsstruktur dieselbe Struktur wie bei der Post? Und strukturiert man sich selbst auch um, wenn die Post Änderungen vornimmt?

Ja, so kenne ich das. Die interne Vertriebsstruktur muss etwa Gebietsreformen nachvollziehen. So haben vor der Reform Adorf und Bdorf je eine Bahnhofstraße. Die Dörfer werden nach Cstadt eingemeindet, die auch eine Bahnhofstraße hat.

Auf jeden Fall ändert sich nun die Straßenbezeichnung in zwei von den dreien.

Und weil eine geografische Abgrenzung (bei langen Straßen sogar nach Hausnummern) eine Mordsarbeit ist, nutzt man einfach das Ergebnis der Post. An die Leitzahlen kommt man leicht dran. Was wäre deine Alternative?

Linuchs

[dedlfix]

Tach!

Und weil eine geografische Abgrenzung (bei langen Straßen sogar nach Hausnummern) eine Mordsarbeit ist, nutzt man einfach das Ergebnis der Post. An die Leitzahlen kommt man leicht dran. Was wäre deine Alternative?

Das kommt doch ganz auf den Anwendungsfall an. Wenn man mit den Post-Grenzen glücklich ist, kann man sich ruhig an das System binden. Wenn man mit Kreisgrenzen glücklich ist, kann man diese nehmen. Wenn man mit Vorwahlnummern-Gebieten ... und so weiter. Wenn das alles nicht auf eigene System passt, muss man da was eigenes machen, zum Beispiel Quadrate auf die Landkarte malen, oder Waben oder Flüsse als Grenzen nehmen, was auch immer.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Danke für diesen Exkurs, aber es geht jetzt überhaupt nicht um Ort oder Postleitzahlen. Ich habe das einfach nur als Beispiel genommen. Es handelt sich also nicht um etwas, womit ich mich gerade beschäftige.

Ich will eigentlich nur _prinzipiell_ wissen, was so die Standardmethode ist, wenn Daten in einer Tabelle nur mit einer Zahl, die auf eine ID einer anderen Tabelle verweist, existieren. Und wie man in der Regel vorgeht, wenn nun neue Daten mittels Formular in jene Tabelle geschrieben werden sollen, wo ein Teil der Information nur mit besagter verweisender Zahl vertreten ist.

_Das_ würde ich gerne wissen.

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Danke für diesen Exkurs, aber es geht jetzt überhaupt nicht um Ort oder Postleitzahlen. Ich habe das einfach nur als Beispiel genommen. Es handelt sich also nicht um etwas, womit ich mich gerade beschäftige.

Das war dann ein nicht ganz glücklich gewähltes, weil es eben Fragen zur prinzipiellen Datenstrukturierung aufwirft, und man am Ende bei solch einem Anwendungsfall vermutlich eine bessere Struktur nimmt und dann das Problem nicht mehr hat.

Ich will eigentlich nur _prinzipiell_ wissen, was so die Standardmethode ist, wenn Daten in einer Tabelle nur mit einer Zahl, die auf eine ID einer anderen Tabelle verweist, existieren.

Das wurde ja schon beantwortet, man zeigt den Namen an und arbeitet intern aber nur mit dem Key, also der Zahl. Wenn man ein mehrstufiges Formular hat, kann man vorher ermittelte Werte ruhig auch über Hidden-Felder mitgeben. Die Manipulierbarkeit ist nicht wirklich ein Problem, wenn man stattdessen auch einfach zurückgehen könnte und einen anderen Wert aus der Auswahlliste wählt. Validierungen sollten sowieso erst am Ende vorgenommen werden. Zwischendurch dient das nur dem Komfort des Anwenders, dass er Werte gleich korrigieren kann.

Und wie man in der Regel vorgeht, wenn nun neue Daten mittels Formular in jene Tabelle geschrieben werden sollen, wo ein Teil der Information nur mit besagter verweisender Zahl vertreten ist.

Die Frage wäre dann erst einmal, wie man das formulartechnisch hinbekommt. Trägt man Werte in die Liste über ein separates Formular ein und hat dann nur eine starre Liste? Nimmt man eine Liste mit festen Werten und daneben ein Eingabefeld für einen Freitext (wenn in der Liste "anderer Wert" gewäht wurde)? Oder macht man sich eine Combobox (Liste und Freitextfeld in einem - geht meines Wissens nur mit Javascript)? Oder nimmt man ein einfaches Feld mit Autocompletion? Je nachdem, wie du dich für deinen Anwendungsfall entscheidest, hast du dann andere Voraussetzugnen, an die eingegebenen Daten zu kommen. Ein Autocompletion-Feld liefert dir nur einen String und keinen Key dazu aus der Datenbank (wenn du nicht was mit einem Hidden-Feld zauberst, das zur Autocompletion dort den Key einträgt). Eine starre Liste liefert dir den Key, den du im Option-Element im value-Attribut eingetragen hast. Die anderen Optionen liefern dir den Key oder einen neuen Text. Letzteren musst du natürlich erst einmal in die Tabelle eintragen, um den Key zu bekommen (bei Autoincrement zumindest).

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Vielen Dank für Deine Ausführungen! Das war in etwa das, was ich wissen wollte.

Mit lieben Grüßen

Melvin Cowznofski

[Linuchs]

Hallo Melvin,

Aus der Tabelle 'Orte' die ausgeschriebenen Ortsnamen auslesen und damit im Formular eine Auswahlliste erstellen.

Nur sinnvoll bei wenigen Orten. Wenn es z.B. um die Mitgliederverwaltung eines Sportvereins geht, kommt man vielleicht mit einem dutzend Nachbarorten aus.

(1. DB Interaktion)

Die Auswahlliste, die schon die ort_id enthält, kann Bestandteil des Adressformulars sein. Anstatt den Ort einzutippen, wählt der Nutzer aus den vorgegebenen Orten.

Wurde eine Name eingegeben und ein Ort ausgewählt, suche ich mir in der Tabelle 'Orte' den ausgewählten Ort und lasse mir die dazugehörende ID ausgeben. (2. DB Interaktion).

Die ort_id wird mitgliefert, du kannst sie noch mal auf Gültigkeit prüfen.

Dann speichere ich den Namen des neuen Mitglieds samt der soeben herausgefundenen Orts-ID in der Tabelle 'Mitglieder'. (3. DB Interaktion)

2. DB Interaktion

Linuchs