Hallo Heiner, Eine Möglichkeit die Datenbank zu vereinfachen wäre, zwei tabellen anzulegen. Eine mit den Firmen und eine mit den personen und nur den Eigenschaften, die bei jeder Person verschieden sind. In die Personentabelle muss dann lediglich ein Feld (z.B. Firmennr.), das eine Person einer Firma zuordnet. So brauchst Du Daten wie die Firmenanschrift nicht für jeden einzelnen Kontakt neu eingeben. Und es fällt Dir später leichter, alle zu einer Firma gehörenden Ansprechpartner zusammen mit den Firmendaten anzeigen zu lassen. Ich weiß ja nicht genau, was Du mit der Tabelle noch vor hast. Viele Grüße Matthias Matthias Wieben Aco Severin Ahlmann GmbH mwieben@aco-online.de -----Ursprüngliche Nachricht----- Von: Heiner Gewiehs [mailto:heiner.gewiehs@gewiehs.de] Gesendet: Dienstag, 19. Oktober 2004 13:59 An: suse-linux@suse.com Betreff: MySQL - Tabellengestaltung - Anfängerfrage Hallo zusammen, ich fummel mir gerade eine Adress-Tabelle zusammen. Nutze hierzu SuSE 8.2 mit MySQL 3.23 Die Felder sollen in etwa so benannt werden: KdnNr. Branche Firma1 Firma2 Abteilung Ressort Anrede1 Geschlecht1 Vorname1 Name1 Anrede2 Geschlecht2 Vorname2 Name2 Anschrift Land PLZ Ort Fon1 Fon2 Fax1 Fax2 Mail1 Mail2 www für jede erledigt Aktion ein neues Feld Kommentar Dies füllt ein DIN A4 Blatt und kommt mir sehr unübersichtlich vor. Darum meine Fragen: Sollte man solch Tabelle in der Größe bestehen lassen? Wie wird solch eine Adresstabelle in der Praxis gestaltet? Wie könnte/solte man das besser gestalten? Ich gebe es zu, die Fragen haben nicht sonderlich viel mit Linux zu tun, auch möchte ich keinen Nachhilfeunterricht über die Liste nehmen, ich möchte auf diesem Weg einfach versuchen, zeitraubende Eigen-Experimente auf ein erträgliches Mass zu reduzieren. Ich hoffe, man sieht es einem Datenbanken-Anfänger etwas nach. Darum hoffe ich auf den einen oder anderen Hinweis oder Tipp, für den ich mich vorab schon sehr herzlich bedanke. Vielen Dank und alles Gute Heiner -- ************************* Heiner Gewiehs Marketing-Fachkaufmann 63868 Grosswallstadt heiner.gewiehs@gewiehs.de ************************* -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

Zitat von Heiner Gewiehs :

ich fummel mir gerade eine Adress-Tabelle zusammen. Nutze hierzu SuSE 8.2 mit MySQL 3.23 Die Felder sollen in etwa so benannt werden:

[...]

für jede erledigt Aktion ein neues Feld Kommentar

Dies füllt ein DIN A4 Blatt und kommt mir sehr unübersichtlich vor.

Dir scheinen für sowas einfach die richtigen Werkzeuge zu fehlen. Lies Dich doch mal ein bißchen zu dem Thema ein - z.B. in den Büchern der Herren Chen und Booch.

Darum meine Fragen: Sollte man solch Tabelle in der Größe bestehen lassen? Wie wird solch eine Adresstabelle in der Praxis gestaltet? Wie könnte/solte man das besser gestalten?

Als allererstes solltest Du Deine Zielanwendung schriftlich fixieren. Welche Aufgaben soll sie lösen, wie soll sie das machen, welche Daten fallen dabei an, welche Prozesse laufen ab? Sowas nennt man Lastenheft, daraus wird dann mittels Mengengerüsten, Test-Szenarien und Feinkonzepten ein Pflichtenheft. Erst wenn man sowas hat, fängt man an zu programmieren. Hint: 80% der Zeit bei der Softwareentwicklung sollte man *nicht* mit dem Rechner verbringen. Normalerweise legt man dann erstmal anhand des Pflichtenheftes fest, welche Entitäten und Attribute man überhaupt so braucht. Das sieht oben schon ganz brauchbar aus. Anschließend bringt man das so gewonnene Datenmodell meistens erstmal in die sogenannte dritte Normalform. "Für jede erledigt Aktion ein neues Feld" z.B. schreit geradezu nach einem Fremdschlüssel. Stichworte: Normalisierung, ER-Modell, Normalform, Relation. Ausgehend vom so gewonnenen normalisierten Modell prüft man nun gegen das erwartete Mengengerüst bzw. gegen die am Anfang festgelegte Spezifikation der Anwendung mit formalen Mitteln vor, ob das so handelbar und performant sein wird. Bei kleineren Datenbanken kann man das oft auch lassen, weil die Hardware da eh so endlos überdimensioniert ist daß Performanceoptimierung fast keine Rolle mehr spielt. Dann ist die 3. Normalform die Datenstruktur, die minimale Redundanz und maximale Pflegbarkeit und Universalität des Modells verspricht. Findet man in diesem Stadium schon Performance-Engpässe (z.B. bei Data-Mining-Anwendungen in großen Beständen passiert das häufig), dann kann man versuchen, diese durch gezielte Denormalisierung (z.B. STAR-Konzept, weitere Normalformen) schon im Ansatz zu entschärfen. Man sollte das Modell auch gegen einige mit dem Lasten- oder Pflichtenheft festgelegte Testfälle prüfen, damit man möglichst früh Fehler wie vergessene Entitäten oder vergessene Attribute oder dergleichen findet. Erst wenn das alles erledigt ist, legt man die Tabellen tatsächlich in einer Datenbank an. Für kleinere Projekte erledigt man die bisherige Arbeit übrigens durchaus am besten mit Papier und Bleistift, auch wenn das wenig populär ist. Danach kann man dann die Funktionsmodule (die man ebenfalls normalisieren oder auf andere Art sinnvoll designen sollte) auf die Datenbank aufsetzen - am besten immer aufeinander aufbauend und mit atomaren Tests nach Fertigstellung jedes Moduls, um möglichst viele Fehler schon früh zu finden. Merke: je später man einen Fehler findet, umso teurer wird er!

Ich gebe es zu, die Fragen haben nicht sonderlich viel mit Linux zu tun, auch möchte ich keinen Nachhilfeunterricht über die Liste nehmen, ich möchte auf diesem Weg einfach versuchen, zeitraubende Eigen-Experimente auf ein erträgliches Mass zu reduzieren. Ich hoffe, man sieht es einem Datenbanken-Anfänger etwas nach.

Als Datenbanken-Anfänger solltest Du Dich zunächst damit beschäftigen, was eine relationale Datenbank eigentlich ist, wie Normalisierung funktioniert und wie man gezielt Datenmodelle sinnvoll aufsetzt. Dazu gibt es endlos viel Literatur. Ein paar Fachbegriffe findest Du in meiner Antwort, Google sollte dazu endlos viel Material liefern. Jede ordentliche Bibliothek, die nicht nur Groschenromane führt, wird geeignete Bücher haben. Ja, die sind zum Teil aus den 1960er Jahren, deshalb aber noch lange nicht veraltet.

Darum hoffe ich auf den einen oder anderen Hinweis oder Tipp, für den ich mich vorab schon sehr herzlich bedanke.

Fang mit der zugrundeliegenden Mathematik an. Mach Dich darauf gefaßt, viel Mengenlehre zu betreiben, denn Relationen sind Beziehungen zwischen Mengen. Du wirst später dankbar dafür sein, denn kaputte oder unsinnige Datenmodelle sorgen mit hoher Wahrscheinlichkeit dafür, daß Du Deine ganze Anwendung irgendwann wegschmeißen und neu machen kannst. Möglicherweise noch bevor sie fertig wird.

-- ************************* Heiner Gewiehs Marketing-Fachkaufmann 63868 Grosswallstadt heiner.gewiehs@gewiehs.de *************************

Die Nettikette empfiehlt übrigens, Signaturen auf 4 Zeilen zu beschränken. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx.net Webhosting - http://webhosting.k-itx.net