Jetzt mal ganz und gar ketzerisch:
Attribute
User ---------
------- ID Bloecke
ID <-------- UserID -----------
Username BlockID ----> ID
Password Attribut Label
Absolute Freiheit!
Andreas Roth
--------------------------------------
[EMAIL PROTECTED] *jetzt mit Chat*
http://www.EuphoriasChild.DarkTech.org
--------------------------------------
> -----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
