![]() |
Datenbank: x • Version: x • Zugriff über: x
Datenbank struktur
Hi Habe mal folgende Frage zum Entwurf der Datenbank
Also ich arbeite ja schon länger mit der BDE und will auch schon länger auf FireBird umstellen Hab mir jetzt mal einiges durchgelesen und habe auch einige Tipps bekommen. Ich habe immer den großen Fehler gemacht und habe alle Daten in eine Tabelle gepackt. :oops: :oops: Jetzt hab ich mal ne Frage zu dem Aufbau. Ist es so richtig das ich z.b. PLZ, Strasse, Telefonnummer, Name, Nachname, Geburtstag usw. in einzelne Tabellen Packe z.B Tabelle_PLZ Tabelle_Strasse Tabelle_Telefonnummer Tabelle_Name Tabelle_Nachname Tabelle_Geburtstag und diese einfach nur mit dem Feld ID und z.b.Name versehen Ich wollte mir diesmal eine strucktur aufbauen bevor ich wieder mist Programmiere |
Re: Datenbank struktur
Moin, Moin,
schau doch mal ![]() |
Re: Datenbank struktur
Aha also hat nur 1 Tabelle eine ID und über die wird ein Fremdschlüßel in die andere Tabelle geschrieben??
|
Re: Datenbank struktur
Ich würde jeder Tabelle eine ID (künstlicher Primärschlüssel) verpassen. allerdings ist eine derart extreme Normalisierung, wie du in deinem ursprünglichen Beitrag hast, nicht unbedingt sinnvoll.
|
Re: Datenbank struktur
Warum wäre das denn nicht sinnvoll
Ich möchte halt Redundaten vermeiden |
Re: Datenbank struktur
Die Daten sollen zwar atomar strukturiert sein, aber von Kernspaltung hat niemand geredet :mrgreen:
|
Re: Datenbank struktur
Also würde Ihr auch die Daten in eine Tabelle speichern und die Datensätze mit einer ID versehen
|
Re: Datenbank struktur
Ich würde das zusammenhanlten, was eigentlich zusammengehört.
Adresse (ID, Str, Plz, Ort) KommAdresse ( ID, Person, Art, Wert) Person ( ID, HauptAdr, Name, Vorname, GebDat, ...) ZuOrdnung (ID, Art, von, zu) |
Re: Datenbank struktur
Aha das ist dochmal was war schon total verwirt
|
Re: Datenbank struktur
Hallo Sascha,
Meine Vorgehensweis: Ich überlege, auf welche Daten im Laufe der Zeit mehrfach verwiesen werden könnte und welche untereinander eine logische Einheit darstellen könnten. In einem größeren System könnte es sich lohnen, für jede Stadt eine Tabelle anzulegen, die Name, Kreis und PLZ enthält. Eine Tabelle, die nur Straßen enthält würde dann auf die Tabelle der Städte verweisen. Es können also beliebig viele Straßen einer Stadt hinzugefügt werden. Ändert sich z.B. die Kreis-Zugehörigkeit einer Stadt musst du nur einen Eintrag in der Tabelle "Stadt" aktualisieren. Eine Tabelle "Geburtstag" hätte nur wenig Sinn, da in einer Datenbank mit wenig Einträgen faktisch jeder Nutzer einen anderen Geburtstag hätte. Man kann diesen Wert also gleich in die Tabelle der Personendaten packen. Sinn für eine weitere Tabelle würde in meinen Augen eine Tabelle für E-Mails machen, aber nur deswegen, weil die Leute in der heutigen Zeit oft mehr als eine E-Mail besitzen. Du könntest also einen Eintrag in der Tabelle "E-Mails" auf den Eintrag einer Person verweisen. (Ich glaube, das heißt 1:n Beziehung, da du beliebig viele E-Mails einer Person zuordnen kannst) Gruß Pfoto |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:17 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz