Meine erste DB, zwei Tabellen verknüpfen

[AlexII]

Hallo,

ich möchte eine DB mit Kontakten erstellen. Eigentlich ist die Datenstruktur(?) einfach, Vorname, Nachname, Wohnort, Telefonnummer usw., eigentlich hätte ich es mit nem Tutorial aufgebaut, aber ich hab vor noch ne Anrede einzufügen, also Herr, Frau... und da weiß ich nicht weiter.

Wie gehe ich in diesem Fall vor, zwei Tabellen erstellen, eine mit Anreden und die andere mit Kontaktdaten und diese irgendwie miteinander verknüpfen? Wenn ja wie verknüpfe ich sie? Und wenn nicht wie mache ich das? :gruebel:

Danke!

[Valle]

Hallo,

ich denke in diesem Fall würde es reichen eine Spalte hinzufügen, die einfach nur bestimmt ob Mann oder Frau. Ich kenne SQL Server Express nicht, aber in MySQL würde es dafür ein Enum oder einfach einfacher Int tun. Wenn der Titel noch mehr als Herr oder Frau beinhalten soll, z.B. eventuelle Doktortitel, dann täte ich eine Varchar-Spalte bevorzugen. :-) Also im Prinzip keine wesentliche Abweichung vom Tutorial, oder?

Liebe Grüße,
Valle

[AlexII]

Ja da kommt mehr rein, Doktor usw...

[Valle]

Eine DB auf jeden Fall. :mrgreen:

Aber ich glaube du meinst eine Spalte in der Tabelle. Ich hätte eine einfache Text-Spalte benutzt in dem Fall. Eine Verknüpfung über eine zweite Tabelle mit JOIN ist zwar möglich, aber da diese zweite Tabelle keine weiteren Daten beinhalten würde, imho unnötig. Aber warte doch besser noch auf ein paar andere Meinungen. :-)

Edit:// Gib doch deinem Thread noch einen aussagekräftigen Titel. Die meisten hier haben eine Frage. :mrgreen:

Liebe Grüße,
Valle

[AlexII]

Ok ich schau ma wie ich diese zwei verbinde.

[Luckie]

Bitte gib deinem Beitrag einen aussagekräftigen Titel. Der jetzige Titel lässt nicht erkennen, um was für ein Problem oder Frage es sich handelt. Um den Titel zu ändern, editiere einfach deinen ersten Beitrag. Damit erleichterst du das Auffinden deines Beitrages mit der Suche und ersparst anderen Mitglieder ein unnötiges Öffnen deines Beitrages.

[Hansa]

Zitat:

Zitat von Valle

Wenn der Titel noch mehr als Herr oder Frau beinhalten soll, z.B. eventuelle Doktortitel, dann täte ich eine Varchar-Spalte bevorzugen. :-)

Herrje, ihr springt viel zu kurz. :mrgreen: Was ist nun aber mit der "Frau Prof. Dr. Dr h.c." :zwinker:

Prinzipiell gibt es IMHO jedenfalls nur zwei Möglichkeiten :

1. Stammtabelle anlegen

D.h. Vergabe der Anrede durch separate Tabelle. Konkret : Anrede wird durch Combobox etc. zugeteilt. Nachteil : Anrede Tabelle muss extra gepflegt werden. Extra-Prommgrammpunkte zur Verwaltung usw. Vorteil : es können ganz eindeutige Listen gewisser ausgewählter Anreden ausgedruckt werden.

2. Normales Char-Feld. Ähnlich, wie Valle sagt. Flexibles Feld und der User kann machen, was er will.

Ich bevorzuge Methode 2. Weil : Suche einfacher. User halten sich sowieso nicht an Vorgaben, z.b. hinter "Dr." muss ein Leerzeichen und dann weiter.

[Luckie]

Zitat:

Zitat von Hansa

Ich bevorzuge Methode 2. Weil : Suche einfacher. User halten sich sowieso nicht an Vorgaben,

Dann wäre doch Lösung eins besser. Dann ist alles einheitlich, weil sie nur die vorgegebenen Auswahlmöglichkeiten haben.

[Hansa]

Luckie, das ist in der Praxis eben komplizierter. Was ist wichtig ? Ratzfatz muss eine Anrede/Adresse angelegt und zugeteilt werden, oder ist das doch nicht ganz so wichtig ? Bsp.: Hatte mal Diskussion in Mainz mit Matthias Eißing. Es ging um Unicode (war damals erst in Planung). Meine Meinung : braucht kaum einer. ABER : da kam Gegenbeispiel. Versicherungspolice. Man stelle sich mal Versicherungsagent vor, der für einen Russen mit chinesischer Frau Police ausdrucken soll. Der muss dann wohl wenigstens die Namen richtig schreiben. Ansonsten drohen bei Rechtsstreit etc. Formfehler im Endeffekt gar Geldverlust. Gilt wohl auch so für Anrede. "Dr." ist z.B. Bestandteil des Namens im Personalausweis, wenn gewünscht. Gehört also eventuell sogar auch nicht zur Anrede, sondern zum Namen.

Bei mir gehts eher darum, alles schnell und unkompliziert machen zu können. Deshalb wird auf unnötige Verwaltungsaufgaben verzichtet. Jeder DAU soll zurechtkommen. :mrgreen:

[Luckie]

Und jeder Dau kann alles durcheinander bringen.

[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! :hi:

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! :cyclops:

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:

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 :shock: : 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. :wall: Wegen des Gemahl-Doktors wollte sie als Frau Dr. angesprochen werden und das sollte ja wohl dann auch der Briefträger sehen. :mrgreen: Beste Anrede ist aber die : "." Warum wohl ?

[Medium]

Zitat:

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:

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. :-D 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... :roteyes:

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

[omata]

Zitat:

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:

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:

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:

Zitat von Valle

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

Das ist dann sehr traurig.

Zitat:

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:

Zitat von omata

Zitat:

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? :gruebel:

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

[DeddyH]

Auch wenn sich der TE bereits bedankt hat vermisse ich bei aller Diskussion um den Sinn einer Speicherung von Anreden in einer eigenen Tabelle (oder eben nicht) eine einfache Erklärung von PKs und FKs. Dann hole ich das mal nach: falls man sich entschließt, die Anreden separat zu halten, so sollte man diese mit mindestens 2 Feldern anlegen (ID und Wert). Die ID sollte dabei "künstlich" sein (Stichwort AutoInc) und den Primärschlüssel (PK) bilden. In der Adresstabelle sollte dann diese ID als Fremdschlüssel (FK) hinterlegt werden (ob nun NULL erlaubt sein soll oder nicht, bleibt in der Entscheidung des Erstellers). Welchen Vorteil hat diese Vorgehensweise? Man hat normierte Daten und nicht bei einer Person die Anrede "Herr" und bei der nächsten die Anrede "Herrn", der Benutzer muss nicht soviel tippen (und kann sich somit nicht so oft vertippen), Änderungen der Stammdaten betreffen nur einen Datensatz und wirken sich sofort auf die betroffenen Detaildatensätze aus (da ja nicht der Wert an sich, sondern nur der Schlüssel dort hinterlegt ist) usw.

[omata]

Im Prinzip sehe ich das auch so. Allerdings wird der PK des Geschlechts (und somit auch die Anreden) als FK bei der Person hinterlegt und nicht bei der Adresse (das macht ja nun gar keinen Sinn)

[DeddyH]

Das hatte ich ja auch gemeint, ist das nicht so rübergekommen?

[edit] Achso, Ihr hattet ja noch eine "Zwischentabelle", dann macht die Aussage natürlich Sinn. [/edit]