Da fehlt noch was:
Attribute
User ---------
------- ID Bloecke
ID <-------- UserID -----------
Username BlockID ----> ID
Password ---NameID Label
| Attribut
|
| AttributName
| ------------
-> ID
Name
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:20
> An: ASP Datenbankprogrammierung
> Betreff: [aspdedatabase] AW: Datenbankdesign
>
>
> 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
| [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
