Meine erste DB, zwei Tabellen verknüpfen

[omata]

Meine Güte macht ihr euch das kompliziert.

Tabelle1 = Person: Titel1, Vorname, Titel2, Nachname
Tabelle2 = Geschlecht: Klartext, Anrede, Anrede2, Briefanrede
Tabelle3 = Adresse: Strasse, PLZ, Ort

Eine Person hat ein Geschlecht.
Eine Person hat eine oder mehr Adressen.

[Valle]

Hallo!

Die Adressen in mehrere Tabellen auszulagern macht ab einem bestimmten Funktionsumfang natürlich Sinn, da hast du Recht. Aber was ich nicht verstehe ist die Aufspaltung in Tabelle1 und Tabelle2. Warum macht man da nicht einfach eine Tabelle draus?

Und noch ein paar Fragen bzgl. Inhalte der zweiten Tabelle. Warum sollte man das Geschlecht in Klartext schreiben, wenn man über eindeutige Sachen (z.B. Enum oder Int) ein wesentlich Maschinen-freundlicheres Format hat? Was ist der Unterschied zwischen Anrede, Anrede2 und Briefanrede?

Also wie man sieht sehen meine DBs bisher anders aus, aber ich lass' mich gern belehren!

Liebe Grüße,
Valle

[Die Muhkuh]

Ich denke mal:

Anrede: Herr / Frau
Anrede2: Prof. Dr. med. dent. weiß gottwas
Briefanrede: Sehr geehrter + Anrede + Anrede2 + Nachname > Sehr geehrte Frau Prof. Dr. med. dent. Hinzundkunz

[Hansa]

Zitat von Valle:

Warum sollte man das Geschlecht in Klartext schreiben, wenn man über eindeutige Sachen (z.B. Enum oder Int) ein wesentlich Maschinen-freundlicheres Format hat? Was ist der Unterschied zwischen Anrede, Anrede2 und Briefanrede?

Dann eben in richtigem Klartext : maschinenfreundlich ist eben <> menschenfreundlich. Also nochmals : Entweder Anrede und das gilt eigentlich auch für ganze Adress-Bestandteile freigeben zur manuellen Eingabe im Klartext, oder eben : Extra-Tabelle mit Lösch-, Editier- und sonstwas Funktion. Nur "Herr/Frau" zuzulassen ist definitiv Kappes. Was nun ? Was ist mit folgender Anschrift zu machen :

Zitat:

FC Bayern München
z.Hd. des Präsidenten Franz Beckenbauer
bla

München

Wat nu ? Der kriegt einmal in 20 Jahren einen Brief, der soll aber schon richtig adressiert sein. In meinem Fall 1. also : Anrede-Stammdaten aufrufen -> Anrede neu anlegen. -> verlassen (am besten Anrede-Nr. merken), alternativ Suchfunktion programmieren und bei Vergessen benutzen -> wieder in eigentliche Adressverwaltung gehen -> Adress-Nr. aufrufen -> neu angelegte Anrede-Nr. zuordnen -> abspeichern. Oder eben all das vergessen und die Anrede als normales CHAR-Feld behandeln. Vielleicht noch Listbox zur Anzeige vorhandener Anreden zur Auswahl einblenden und fertig.

P.S.: Bin gerade mal Real-Daten durchgegangen, bei denen das Konzept mit der Extra-Tabelle durchgezogen wurde. Da sind Anreden, auf die kommt man nicht mal so einfach "Herr und Frau Dr.". Ja, da hat die Gattin auch gedacht, wenn sie schon einen König heiratet, dann sei sie selber Königin. Wegen des Gemahl-Doktors wollte sie als Frau Dr. angesprochen werden und das sollte ja wohl dann auch der Briefträger sehen. Beste Anrede ist aber die : "." Warum wohl ?

[Medium]

Zitat von omata:

Tabelle1 = Person: Titel1, Vorname, Titel2, Nachname
Tabelle2 = Geschlecht: Klartext, Anrede, Anrede2, Briefanrede
Tabelle3 = Adresse: Strasse, PLZ, Ort

Tabelle1: alle Felder null
Tabelle2: Klartext: "FC Bayern München"; Briefanrede: "z.Hd. des Präsidenten Franz Beckenbauer"; Rest null
Tabelle3: entsprechend

Und schon kann man dennoch wunderbar mit DropDown-Boxen die Titel und Anreden benutzen, ohne dass sie in solchen Fällen stören, oder die DB teilweise Zweckentfremden müssten. Mir gefällt diese Aufteilung, je mehr ich drüber nachdenke, ausgesprochen gut!

Edit:

Zitat:

Beste Anrede ist aber die : "." Warum wohl ?

Das CHAR-Feld auf not-null gedonnert? Macht wenig Sinn, und ist daher klar ein Designfehler. Firmen z.B. benutzen eben keine Anrede. Das ist aber kein Problem der Aufteilung an sich, sondern lediglich dieses einen Feldes.

[Hansa]

Zitat von Medium:

Zitat:

Beste Anrede ist aber die : "." Warum wohl ?

Das CHAR-Feld auf not-null gedonnert? Macht wenig Sinn, und ist daher klar ein Designfehler. Firmen z.B. benutzen eben keine Anrede. Das ist aber kein Problem der Aufteilung an sich, sondern lediglich dieses einen Feldes.

Netter Versuch. Ne, Ihr unterschätzt die Findigkeit der User ! Im Anrede-Feld muste ein Wert und eben eine Anrede angegeben werden. Basta. So war meine Vorgabe. Aber Denkste ! Da es zuviel Arbeit war, für speziellen Brief (deshalb Beispiel Beckenbauer) extra Anrede anzulegen hatten sie eine :

Zitat:

.
.
.

.

Adresse zusammengebastelt. Perfekt, um von Hand oder Schreibmachine was reinzuhacken. Die "." gehen unter dem Kuli wohl unter. Deshalb war klar : separate Tabelle ist sinnlos. Allgemeingültigist das aber nicht ! Siehe Versicherungspolice.

[Medium]

Was der User am Ende draus macht, steht ohnehin immer auf einem ganz anderen Blatt, und bei so offenen "Systemen" wie Postanschriften muss man schlicht entweder so viel Freiheiten einräumen, dass man es in der Anwendung vermurksen kann, oder man lässt sich drauf ein für jede Formular-Art eine separate Maske zu erstellen.

Allerdings: "Im Anrede-Feld muste ein Wert und eben eine Anrede angegeben werden. Basta." kommt einem not-null Feld relativ nahe. Es ist halt nicht in der DB definiert, aber die Eingabemaske hat für den User dann den selben Effekt. Es ginge bei Strings ja sogar ohne null - einfach Leerstrings zulassen

[AlexII]

Nach dieser Diskussion weiß ich jetzt weniger als vorher...

Aber ok, danke! Hab trotzdem was für mich entnommen.

[omata]

Zitat von Valle:

...Warum macht man da nicht einfach eine Tabelle draus?

Weil das redundant wäre, immer alle Anreden bei jeder Person wieder neu zuspeichern.

Man muss hier ja auch mal etwas mehr über den Tellerrand schauen. Was ist, wenn ich mal mit Standardsoftware wie z.B. Mircosoft Word oder Excel auf die Daten in der Datenbank zugreifen will. Genau aus dem Grund ist es sehr sinnvoll alle Daten in der DB zu haben und nicht mit Wenn ... dann so etwas immer wieder nach zubauen. Also wenn hier wirklich einer auf die Idee kommt soetwas hart im Programm zu hinterlegen, dann tut er mir richtig leid. Ein weiteres Stichwort sind hier mehrere Sprachen.

Zitat von Valle:

...Warum sollte man das Geschlecht in Klartext schreiben, wenn man über eindeutige Sachen (z.B. Enum oder Int) ein wesentlich Maschinen-freundlicheres Format hat?

Wieso das? Die Tabelle "Geschlecht" erhält natürlich eine ID als PK und dann hat man auch diese Information als INT (was man aber eher über einen zusätzlichen Typ (char(1)) lösen sollte oder eben auch diesen schon als PK einführen. Trotzdem macht der Klartext durchaus Sinn, wenn man mal weiblich / männlich als Auswahlkriterium heranziehen oder dies textuell ausgeben möchte. Die vorgeschlage Struktur macht es so einfach und ist erweiterbar und die vereinfachten Vorschläge machen es nur kompliziert (naja, warum einfach, wenn es auch kompliziert geht).
Außerdem geht es nie um Maschinenfreundlichkeit sondern immer um Menschenfreundlichkeit. Sonnst braucht man auch nicht in einer Hochsprache programmieren und kann bei Assembler bleiben.

Zitat von Valle:

Was ist der Unterschied zwischen Anrede, Anrede2 und Briefanrede?

Anrede = Herr / Frau
Anrede2 = Herrn / Frau
Briefanrede = Sehr geehrter Herr / Sehr geehrte Frau

Zitat von Valle:

Also wie man sieht sehen meine DBs bisher anders aus...

Das ist dann sehr traurig.

Zitat von Die Muhkuh:

Anrede2: Prof. Dr. med. dent. weiß gottwas

Ganz bestimmt nicht!
Prof. oder Dr. sind keine Anreden! sondern Titel!
Schmeißt hier doch nicht alles durcheinander.

Das c/o oder z.Hd. Feld gehört zur Adresse und kann dort einfach als zusätzliche Spalte aufgenommen werden. Beides kann in der selben Spalte abgelegt werden, dann muss eben in dem Fall das zugehörige Kürzel mit vorangestellt werden (das ist völlig unkritisch)

Ich kenne diese Diskussion und führe sie nicht zum ersten mal (hier schon). Und ich frage mich, warum man das Problem (und es ist gar keins) nicht einfach gleich ordentlich lösen kann. Warum muss hier immer so ein Eiertanz (vielleicht weil wir Ostern haben? -> nein!) drum gemacht werden?

[Valle]

Zitat von omata:

Zitat von Valle:

Also wie man sieht sehen meine DBs bisher anders aus...

Das ist dann sehr traurig.

Mh okay, ich verstehe mittlerweile den sehr entscheidenden Unterschied hier. Meine Datenbanken beinhalten zumeist Profile auf Webseiten. Die genannten Anforderungen benötige ich überhaupt nicht. Ein Datenbank-Dump brauche ich nicht, da eh keiner Zugriff auf die DB direkt hat. Auch Anreden usw. sind unnötig, weil ich in meiner privaten Community keine Briefe verschicke. E-Mails und PMs gehen in der "Du"-Form raus. Redundanzen entstehen dabei nicht. Die maschinenfreundlichen Formate verkleinern die Datenbank und erhöhen die Performance. Warum sollte ich in einer Webapplikation auch eine menschenfreundliche DB haben?

Okay, also ich denke DBs in mehr oder minder privaten Homepages und in professionellen, kommerziellen Firmen unterscheiden sich doch stark. Man sollte hier zu gunsten des TE eventuell genauere Bedürfnisse abklären.

Ansonsten Danke, omata!

Liebe Grüße,
Valle