ilch Forum » Ilch Clan 1.1 » Allgemein » DB normalisierung

Geschlossen
  1. #1
    User Pic
    google.de Mitglied
    Registriert seit
    26.01.2012
    Beitrge
    352
    Beitragswertungen
    33 Beitragspunkte
    Hallo Community,
    dieser entstand aus der Neugier herraus. Ich habe bis jetzt noch kein CMS / Webseite gesehen die bis zur 3. Normalform normalisiert wurde. Warum werden in "Webanwendungen" transitive Abhängikeiten geduldet. Sind die Performence einbußen den erhöhten Speicherbedarf gleichwertig anzurechnen? In heutiger sicht ist DB-Speicher genug zur Verfügung und auch traffic ist eigentlich kein Thema mehr aber wenn man mal vom theoretischen ausgeht.

    Theoretische Konstelation:
    Tabellen Engine: MyISAM
    Zeichensatz latin1
    Tabellenkonstellation (Ilch user)
    id 	        int(10) 	 5 Byte
    name 	        varchar(50) 	 51 Byte
    pass 	        varchar(32) 	 33 Byte
    recht 	        int(1) 	  	 1 Byte
    posts 	        int(5)    	 3 Byte
    regist  	int(20)          9 Byte
    email   	varchar(100)     101 Byte
    llogin  	int(20)          9 Byte
    spezrank 	mediumint(9)     4 Byte
    opt_pm  	tinyint(1)       1 Byte
    opt_pm_popup 	tinyint(1) 	 1 Byte
    opt_mail 	tinyint(1) 	 1 Byte
    status  	tinyint(1) 	 1 Byte
    geschlecht 	tinyint(1) 	 1 Byte  
    gebdatum 	date             3 Byte
    wohnort 	varchar(50)      51 Byte
    homepage 	varchar(100)     101 Byte
    staat   	varchar(50)      51 Byte
    avatar  	varchar(100)     101 Byte
    icq     	varchar(20)      21 Byte
    msn     	varchar(50)      51 Byte
    yahoo   	varchar(50)      51 Byte
    aim     	varchar(50)      51 Byte
    sig     	text             Anzahl der Zeichen + 2 Byte (80 Zeichen)
    
    
    Ergebnis:                        786 Byte


    Also "kostet" jeder neue User 771 Byte. Wenn ich jetzt die Transitiven Abhängikeiten herrauslöschen dann könnte man folgende Effizienz erwirtschaften:

    
    wohnort 	    unsigned SMALLINT()     2 Byte
    staat   	    unsigned TINYINT()      1 Byte
    
    opt_pm  	tinyint(1)       1 Byte
    opt_pm_popup 	tinyint(1) 	 1 Byte
    opt_mail 	tinyint(1) 	 1 Byte


    somit würde folgende DB-Tabellenstruktur übrigbleiben:

    id 	        int(10) 	 5 Byte
    name 	        varchar(50) 	 51 Byte <--- auf varchar(25) 26 Byte
    pass 	        varchar(32) 	 33 Byte
    recht 	        int(1) 	  	 1 Byte
    posts 	        int(5)    	 3 Byte
    regist  	int(20)          9 Byte
    email   	varchar(100)     101 Byte <--- auf varchar(50) 51 Byte
    llogin  	int(20)          9 Byte
    spezrank 	mediumint(9)     4 Byte
    opt_pm  	tinyint(1)       1 Byte <--- weg
    opt_pm_popup 	tinyint(1) 	 1 Byte <--- weg
    opt_mail 	tinyint(1) 	 1 Byte <--- weg
    FS:rel_pm_pmPopup_mail tinyint(1) 1 Byte <--- hinzu
    status  	tinyint(1) 	 1 Byte
    geschlecht 	tinyint(1) 	 1 Byte  
    gebdatum 	date             3 Byte
    wohnort 	varchar(50)      51 Byte <--- weg
    FS:wohnort      unsigned mediumint 3 Byte <--- hinzu
    homepage 	varchar(100)     101 Byte <--- auf varchar(50) 51 Byte
    staat   	varchar(50)      51 Byte <--- weg
    FS:staat       unsigned tinyint() 1 Byte <--- dazu
    avatar  	varchar(100)     101 Byte <--- auf varchar(50) 51 Byte
    icq     	varchar(20)      21 Byte
    msn     	varchar(50)      51 Byte
    yahoo   	varchar(50)      51 Byte
    aim     	varchar(50)      51 Byte
    sig     	text             Anzahl der Zeichen + 2 Byte (80 Zeichen)
    
    
    Ergebnis:                        512 Byte


    somit wäre eine Erspranis von 274 Byte pro User nur in dieser Tabelle erreicht!

    Natürlich muss man noch die Relationen die dafür dazu kommen mit einberechnen und eine Warscheinlichkeit das Datensatz X N-fach vorkommt.
    Doch um das weiter auszuführen ist es jetzt ein bischen spät.

    Es würde mich freuen wenn dies eine kleine Diskusion entfachen würde lcheln


    Zuletzt modifiziert von google.de am 04.03.2012 - 22:14:24
    Kein Support per PN!
    Wenn ich zitiere ist dies KEIN Angriff auf die Person!
    0 Mitglieder finden den Beitrag gut.
  2. #2
    User Pic
    Mairu Coder
    Registriert seit
    16.06.2006
    Beitrge
    15.320
    Beitragswertungen
    377 Beitragspunkte
    Naja meines Wissens belegt Varchar nur soviele Bytes wie Zeichen drin stehen +1 bzw +2 bei Varchars über 255 Zeichen, und ja es wäre sicher nicht verkehrt für Profilfelder, die nur im Profil oder zumindest nicht oft angezeigt werden eine weitere Tabelle zu erstellen, ansonsten sind JOINs sprich Rechenzeit auf jeden Fall eher zu vermeiden, als ein paar mehr Daten auf der Festplatte.
    Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite
    0 Mitglieder finden den Beitrag gut.
Geschlossen

Zurck zu Allgemein

Optionen: Bei einer Antwort zu diesem Thema eine eMail erhalten