So dachte ich das. Wenn ich n�mlich anhand der UserID nach der Table USER_PERSONALIEN frage und die nicht existiert, wei� ich, dass der User noch keine Personalien eingeben hat.
Alternativ muss ich bei einer Tabelle entweder ein Boolean Feld Personalien einf�gen oder aber ein Feld dazu mi�brauchen... Da finde ich eigentlich obiges sch�ner -----Urspr�ngliche Nachricht----- Von: Andreas Roth [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Januar 2002 22:05 An: ASP Datenbankprogrammierung Betreff: [aspdedatabase] AW: Datenbankdesign > > Diese Regel kannte ich noch nicht. > ist f�r mich eine Grundregel. Man kann das nat�rlich auch �bertreiben, wenn man dann alle Attribute in eigene Tabellen auslagert, die NULL sein k�nnten. Aber die Idee, Das in Bl�cke aufzuteilen finde ich grunds�tzlich nicht falsch. Im Beispiel von Andreas richten sich diese ra ein wenig nach der vom User genutzten Applikation Tabelle: Daten f�r Login Tabelle f�r Ausf�hrlichere Informationen (zB. Mitarbeiterverzeichniss) Tabelle f�r Snitz-Forum �quivalent (ICQ Nummer usw. Wenn man davon ausgeht, dass ein User sich erstmal anmeldet, ohne dass er alles nutzt wird eine Tabelle so Initialisiert: ID Nickname Passwort Vorname Nachname Adresse Telefon Email ICQ_Nr MSN_Name AIM_Name BildURL 1 Euphoria blabla NULL NULL NULL NULL NULL NULL NULL NULL NULL Mit 3 Einzelnen Tabellen kann man auch sch�n nachvollziehen, ob jemand eine bestimmte Teilapplikation nutzt (und zB. einen Link anbieten wenn, ansonsten zum anmelden) Auf die Weise f�llt es auch viel leichter neue Attribute einzuf�gen, ohne das Design in irgendeiner Form verwirrend zu gestalten. Andreas Roth -------------------------------------- [EMAIL PROTECTED] *jetzt mit Chat* http://www.EuphoriasChild.DarkTech.org -------------------------------------- > -----Urspr�ngliche Nachricht----- > Von: Joachim van de Bruck [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 31. Januar 2002 21:45 > An: ASP Datenbankprogrammierung > Betreff: [aspdedatabase] AW: Datenbankdesign > > > Hallo! > > > F�r meine Userumgebung (EC-Suite) stehe ich vor der selben > Entscheidung. > > Letztlich will ich auch noch das Ankn�pfen an vorhandene > > Benutzerdaten erm�glichen. Und wenn ich sp�ter Applikationen daf�r > > Schreibe, kommen vielleicht neue Attribute f�r die User dazu (zB. > > Standard Icon im > Chat). > > Eigentlich kann man die Grundregeln des Datenbankdesigns > ber�cksichtigen. > > Wenn ein Attribut nicht unbedingt erforderlich ist, sollte man es > auslagern. > > Wenn du also Namen und Adresse nicht f�r jeden Angemeldeten User > ben�tigst, > > sollten sie in eine andere Tabelle. > Wenn bestimmte Felder nicht immer angegeben werden, dann haben die bei > mir den Wert NULL und zwar in der gleichen Tabelle. Wenn eine > Anwendung nicht alle Felder ben�tigt, gibt es eine View, die nur die > ben�tigten Daten liest. > > Das Geburtsdatum, die Telefonnummer o. �. einer Person steht also > immer bei der Person wegen der direkten funktionalen Abh�ngigkeit, es > sei denn man hat mehrere Telefonnummern oder Geburts- und Ehrentage, > die man zu einer Person speichert. > > Freundliche Gr��e > Joachim van de Bruck > > > > > | [aspdedatabase] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv Sie > | k�nnen sich unter folgender URL an- und abmelden: > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp | [aspdedatabase] als [EMAIL PROTECTED] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv Sie | k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
