13
Datenbank gut geplant?
HI Experten,
zur Zeit befasse ich micht etwas mit der Entwicklung von Webanwendungen. Dazu habe ich eine kleine Anwendung gebastelt. Zum lernen und testen habe ich auf die ordentliche Planung der Datenbank verzichtet (Fragt nicht warum
)
Am System können sich Benutzer registrieren und dann auch Anmelden. Nach efolgreicher Anmeldung können Benutzer neue "Kunden" anlegen und Ihnen dann Briefe schreiben, welche auch in der Datenbank gespeichert werden .
Dazu habe ich mir jetzt diese Datenbakstruktur überlegt.
Unterstrichen sind die Primärschlüssel und Fett sind die Fremdschlüssel
Tabelle User:
username,passwort,berechtigungslevel,fail_counter
Tabelle Kunden:
kundennummer,anrede
Tabelle adressen:
vorname,nachname,strasse,plz,ort,username,kundenname
Tabelle brief:
id,titel,text,zeitstempel,username,kundennummer
Was denkt Ihr? kann man das so lassen oder hat jemand verbesserungsvorschläger oder sogar eine komplett andere Lösung? Danke euch schon mal für die Hilfe
Gruß
tobmes
zur Zeit befasse ich micht etwas mit der Entwicklung von Webanwendungen. Dazu habe ich eine kleine Anwendung gebastelt. Zum lernen und testen habe ich auf die ordentliche Planung der Datenbank verzichtet (Fragt nicht warum
)Am System können sich Benutzer registrieren und dann auch Anmelden. Nach efolgreicher Anmeldung können Benutzer neue "Kunden" anlegen und Ihnen dann Briefe schreiben, welche auch in der Datenbank gespeichert werden .
Dazu habe ich mir jetzt diese Datenbakstruktur überlegt.
Unterstrichen sind die Primärschlüssel und Fett sind die Fremdschlüssel
Tabelle User:
username,passwort,berechtigungslevel,fail_counter
Tabelle Kunden:
kundennummer,anrede
Tabelle adressen:
vorname,nachname,strasse,plz,ort,username,kundenname
Tabelle brief:
id,titel,text,zeitstempel,username,kundennummer
Was denkt Ihr? kann man das so lassen oder hat jemand verbesserungsvorschläger oder sogar eine komplett andere Lösung? Danke euch schon mal für die Hilfe
Gruß
tobmes
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 313573
Url: https://administrator.de/contentid/313573
Ausgedruckt am: 26.11.2024 um 10:11 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
auf den ersten blick schon mal die Tabelle Adressen.
So Namenskombinationen könne durchaus öfter vorkommen.
auf den ersten blick schon mal die Tabelle Adressen.
So Namenskombinationen könne durchaus öfter vorkommen.
Hallo tobmes,
also, ich gehe mal langsam durch:
Tabelle User:
Benutzername, Anrede, Vorname, Nachname, Strasse, PLZ, Ort, Passwort, Berechtigungslevel, Fail_Counter
Tabelle Kunde:
Kundennummer, Anrede, Vorname, Nachname, Strasse, PLZ, Ort
Tabelle Brief:
Sendungsnummer, Titel, Text, Zeitstempel, Benutzername, Kundennummer
Die Adressen solltest du mit in die jeweilige Tabelle nehmen, denn ein Feld von "Benutzername" und "Kundennummer" in der Tabelle "Adressen" würde immer leer bleiben, das ist nicht sehr praktisch, zumal die beiden auch noch Fremdschlüssel sind...
LG, Sascha
also, ich gehe mal langsam durch:
Tabelle User:
Benutzername, Anrede, Vorname, Nachname, Strasse, PLZ, Ort, Passwort, Berechtigungslevel, Fail_Counter
Tabelle Kunde:
Kundennummer, Anrede, Vorname, Nachname, Strasse, PLZ, Ort
Tabelle Brief:
Sendungsnummer, Titel, Text, Zeitstempel, Benutzername, Kundennummer
Die Adressen solltest du mit in die jeweilige Tabelle nehmen, denn ein Feld von "Benutzername" und "Kundennummer" in der Tabelle "Adressen" würde immer leer bleiben, das ist nicht sehr praktisch, zumal die beiden auch noch Fremdschlüssel sind...
LG, Sascha
Vielen Dank für eure schnellen Antworten. Dann werde ich das etwas umbauen müssen. Dachte irgendwie das es geschickt wäre die Adressen auszulagen. Scheint ja nicht so zu sein
Tipp: Lies dir mal was zu Normalformen durch (http://www.oszhandel.de/gymnasium/faecher/informatik/datenbanken/normal ..).
Wenn du das verstanden hast sollte es dir klarer werden, warum man das so nicht macht.
Wenn du das verstanden hast sollte es dir klarer werden, warum man das so nicht macht.
Was ich machen würde: Ich würde in JEDE Tabelle ein Feld "id" (int, auto-increment) einfügen, DAS ist der primärschlüssel. Denn dein Benutzername bräuchte dann nicht mal eindeutig sein, solange Benutzername und Passwort übereinstimmt hast du eine eindeutige ID. Spätestens wenn du mal einen Benutzer löscht und sich ein anderer Benutzer mit selben Usernamen anmeldet hast du sonst auch immer Spass.
Ganz davon abgesehen wäre bei großen Datenmengen ein Vergleich des INT-Wertes um ein vielfaches schneller als der eines String....
Ganz davon abgesehen wäre bei großen Datenmengen ein Vergleich des INT-Wertes um ein vielfaches schneller als der eines String....
Additionaly I would add the field "username" to the table "Kunden" so that these data sets can be assigned to the account. I wouldn't like to see addresses of other clients in my account 
Regards
Regards
Naja, der Benutzername sollte optimaler Weise schon eindeutig sein, denn wie soll jemand sonst 2 Accounts auseinanderhalten?
Passwörter werden üblicherweise verschlüsselt abgespeichert, dementsprechend sollte das Passwort auch überhaupt gar nicht irgendwo genutzt werden, außer zur Authentifizierung...
Passwörter werden üblicherweise verschlüsselt abgespeichert, dementsprechend sollte das Passwort auch überhaupt gar nicht irgendwo genutzt werden, außer zur Authentifizierung...
Das würde aber voraussetzen, dass:
- entweder jeder Kunde auch einen Account hat, oder
- jeder Kunde genau einem Benutzer zugeordnet werden kann, was ein Problem wäre, da Kunden auch mehrere "Lieferanten/Hersteller" oder was auch immer haben können.
Zitat von @veniplex:
Das würde aber voraussetzen, dass:
No, I understand that the user creates these personal contacts (Kunden) so they belong to his account. Otherwise he needs an additional table which records the assignment, or do you want to see the contacts of other registered users in your account ?? Das würde aber voraussetzen, dass:
- entweder jeder Kunde auch einen Account hat, oder
Da müsste man natürlich klar definieren was man will. Wenn man das so sieht wie highload, hat er recht!
Ich dachte eher daran, dass es Kunden und User gibt, und Kunden in dem Fall auch zu mehreren Usern gehören können.
Man muss die Beziehung festlegen: 1:1 oder 1:n?
Ich dachte eher daran, dass es Kunden und User gibt, und Kunden in dem Fall auch zu mehreren Usern gehören können.
Man muss die Beziehung festlegen: 1:1 oder 1:n?
Hi,
also ich sehe schon das ist nicht so einfach, wie ich mir das vorgestellt habe. Stimmt aber, es wäre ja eigentlich nicht schlecht, wenn ein User einen "Kunden" anlegt, das nur er diesen Kunden auch sehen kann.
also ich sehe schon das ist nicht so einfach, wie ich mir das vorgestellt habe. Stimmt aber, es wäre ja eigentlich nicht schlecht, wenn ein User einen "Kunden" anlegt, das nur er diesen Kunden auch sehen kann.
Man kann das Ganze auch noch auf die Spitze treiben.
Wenn man davon ausgeht, dass Vor-, Nach-, Orts- und Strassennamen in den Adressen sich ständig wiederholen und man die Daten redundant speichern will, kann man bei sehr großen Datenmengen damit Speicher sparen:
Tabelle Benutzer
BenutzerId,VNameId,NNameId,BenutzerName,KundenNummer,Berechtigung,FailCounter
Tabelle Vornamen
VNameId,VorName
Tabelle NachNamen
NNamenId, NachName
Tabelle Kunde
Kundennummer,AdressId,E-Mail
Tabelle Orte
OrtId OrtName
Tabelle Strassen
StrassenId StrassenName
Tabelle PLZ
PlzId PLZ
Tabelle Adresse
AdressId,PlzId,StrassenId,OrtId,HausNummer
Tabelle Sendung
SendungId,Titel,Text,Zeitstempel,Benutzername,EmpfängerId
Das macht dann aber u.U. die Applikation ganz schön aufwendig, denn man muss natürlich dann auch darauf achten, dass man keine Dupletten abspeichert. z.B.
OrtId Ort
1 Berlin
2 BERLIN
Wenn man davon ausgeht, dass Vor-, Nach-, Orts- und Strassennamen in den Adressen sich ständig wiederholen und man die Daten redundant speichern will, kann man bei sehr großen Datenmengen damit Speicher sparen:
Tabelle Benutzer
BenutzerId,VNameId,NNameId,BenutzerName,KundenNummer,Berechtigung,FailCounter
Tabelle Vornamen
VNameId,VorName
Tabelle NachNamen
NNamenId, NachName
Tabelle Kunde
Kundennummer,AdressId,E-Mail
Tabelle Orte
OrtId OrtName
Tabelle Strassen
StrassenId StrassenName
Tabelle PLZ
PlzId PLZ
Tabelle Adresse
AdressId,PlzId,StrassenId,OrtId,HausNummer
Tabelle Sendung
SendungId,Titel,Text,Zeitstempel,Benutzername,EmpfängerId
Das macht dann aber u.U. die Applikation ganz schön aufwendig, denn man muss natürlich dann auch darauf achten, dass man keine Dupletten abspeichert. z.B.
OrtId Ort
1 Berlin
2 BERLIN
Moin tobmes,
Kann ja Kunden geben, die mit 5 Usern Geschäftsbeziehungen haben. Das würde bei dem Datenmodell dazu führen, dass der Kunde 5x angelegt wird mit Name, Anschrift, Telnr, ...
Wenn es also auch eine n:m-Beziehung sein kann, dann brauchst du eine weitere Tabelle mit Userid und Kundenid.
Grüße
Biber
Zitat von @tobmes:
...es wäre ja eigentlich nicht schlecht, wenn ein User einen "Kunden" anlegt, das nur er diesen Kunden auch sehen kann.
Ist auch zu kurz gegriffen....es wäre ja eigentlich nicht schlecht, wenn ein User einen "Kunden" anlegt, das nur er diesen Kunden auch sehen kann.
Kann ja Kunden geben, die mit 5 Usern Geschäftsbeziehungen haben. Das würde bei dem Datenmodell dazu führen, dass der Kunde 5x angelegt wird mit Name, Anschrift, Telnr, ...
Wenn es also auch eine n:m-Beziehung sein kann, dann brauchst du eine weitere Tabelle mit Userid und Kundenid.
Grüße
Biber
