Hallo Andreas, > > Das kann man so aufsetzen, wenn man die Orte für die Adressen wirklich > trennt. Gibt es einen Fall, wo dies sinnvoll ist? Ansonsten kann man > eine Adresse als einen Datensatz behandeln und schreibt diese Daten > in eine Tabelle in eine Zeile.
Sofern es nicht große Umstände macht erledige ich so etwas eigentlich grundsätzlich. Und da das über Comboboxen und Makros reibungslos funktioniert und bei der Eingabe kein Hindernis darstellt habe ich das auch an andere Stelle bereits so umgesetzt. > > Die getrennte Abbildung von Orten und PLZen hat den Nachteil, dass man > nicht sehr gut Stadtteile oder ähnliches abbilden kann, erst Recht > nicht, wenn man die von der Post gelieferten Magnetbanddaten zu Grunde > legt. Die sind ja nicht getrennt. Der Ort ist per ID mit der Postleitzahl verbunden die wieder per ID mit der Adresse verbunden sind. Wähle ich eine Postleitzahl, so ist der dazugehörige Ort automatisch verknüpft. > > > Straßen sind von den Orten und Postleitzahlen recht unabhängig, da > > gleiche Bezeichnungen in unterschiedlichen Orten auftauchen. Also > > gehören die nicht in diese Reihe. > > Die eigentliche Frage ist: will ich Orte, Straßen und Hausnummern > getrennt ansprechen? Oder will ich Adressen speichern. Beim zweiten > Fall würde sich nämlich folgendes Problem von alleine erledigen: > > Die Adressen werden separat erfasst, weil zumindest in unserem Verein > > zwar 500 Mitglieder, aber nur ca. 270 anzuschreibende Adressen > > existieren. Liegt einfach daran, dass natürlich Ehepaare und Familien > > mit gleichen Adressen auftauchen. > > Wenn ich die Adresse als Datensatz speichere, verweise ich auf genau > einen Datensatz. Dann ist dieses Problem keines mehr. Ich speichere die Adresse doch als genau einen Datensatz. Ich brauche bloß die Postleitzahl und den Ort auch noch für andere Leute, und deshalb hae ich natürlich den Ort und die Postleitzahl aus der Adressenliste ausgelagert. In der Mitgliedertabelle habe ich nur eine ID, die auf die Adresse verweist, die wiederum eine ID hat, die auf die Postleitzahl verweist. > Außerdem: > > Deswegen will ich natürlich die Adressen nicht zweimal schreiben und > > auch beim Umzug nicht doppelt korrigieren. > > Doppelte Adressen gäbe es dann nicht mehr, das würde ein > Unique-Constraint verhindern. Bei einem Umzug entscheidet man entweder, > ob die Adresse geändert wird oder ob eine neue Adresse angelegt und die > Verknüpfung geändert wird. Beides ist möglich > > > Wenn nur Teile der Familie umziehen, muss ich hier eine > > Abfrage einbauen "Sollen alle Adressen der Familie geändert werden?". > > Der aktuelle Aufbau lässt aber imho auch keine sauberen "Umzüge" eines > Teils der Familie zu. Sicher, ich brauche doch nicht bei allen Mitgliedern die Änderung durchzuführen. Die Abfrage muss natürlich vor dem Speichern erfolgen, damit die Adresse gegebenenfalls nur bei dem aktuell aufgerufenen Mitglied geändert wird. Dass das mit Base etwas aufwändiger erscheint als bei dem für mich vertrauteren PHP/Javascript sollte dabei kein Hindernis sein. > > > > So, genug Datenbanktheorie ;-) > > Es ist immer ein Abwägen zwischen der reinen Lehre der Normalisierung > und dem praktischen Einsatz. Stark normalisierte Datenbanken sind in > der Regel sehr performant ansprechbar, brauchen aber auch > administrativ mehr Platz (zusätzliche Indexes ect) und verkomplizieren > das Erklären des Datenmodells. Damit hast Du sicher Recht. Deswegen erfordert der Tabellenaufbau ja vorher eine Diskussion aller Beteiligten, denn am einfachsten wäre es natürlich für zukünftige Datenbänkler, wenn es nur eine Tabelle gäbe - nur bringen dann naturgemäß Abfragen nicht viel. Dennoch waren bei mir die Schüler heute wieder Stolz, als aus der ersten Tabelle mit lediglich einer Ware und dem dazugehörigen Preis ein Formular mit zwei Eingabefeldern erzeugt wurde - übrigens mit Einsatz des Asssistenten, da die Sache sonst gut die vierfache Zeit benötigen würde. Ich arbeite noch an einer Beschreibung der Relationen und stelle die vermutlich erst Morgen ins Netz. Gruß Robert --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
