aussage...
 

Im folgenden möchte ich gern die Aussagen welche in einer welche mir
gegenüber gemacht wurden zur Diekussion stellen.

Die Aussage bezieht sich auf eine Datenbank in der ein Datensatz eines
Users mit einer ID in einer Tabelle abgelegt wird, die eMail-Adresse und
die Handynummer jeweils in einer eigenen, auch mit der ID um die
Datensätze zu verbinden.

Meiner Ansicht nach macht das nur Sinn, wenn man pro User mehrere
eMail-Adresse oder Handynummern speichern will, mein Kontrahent nennt
die folgenden Argumente:

> 1. Sollte man darauf achten Tabellen immer in übersichtlichere
Teiltabellen zu zerlegen.
> Dies verhindert auch das Risiko für anomalien.
> 2. Der wichtigste Punkt:
>
> Nach deiner Methodik würde für jede Column eines Users in der nichts
drinnen steht, trotzdem Speicherplatz reserviert werden der aber nicht
genutzt wird. (z.B. verlangsamt das natürlich auch die DB-Operationen
die Du auf diese Tabelle ausführst).
> Bei meinem Modell hingegen (welches nicht nur übersichtlicher &
leichter zu pflegen ist) lege ich für jeden User nur die Datensätze (in
den Tabellen an) an die er auch wirklich benötigt.
>
> Ich habe es mit einer vielzahl von möglichen Usern mit
unterschiedlichen Eigenschaften zu tun.
> Jeder User kann aber seine Eigenschaften verändern.
>
>
> Das mit dem Speicherplatz und der Performance ist im Gegensatz zu so
Hobby-mysql Datenbanken z.B. kleinere bis mittlere Webshops für meine
Datenmengen sehr entscheiden & machts sich durch die hohe Anzahl von
"simultanen" DB-Zugriffen auch direkt bemerkbar.
>
> Ein netter Nebeneffekt ist auch noch, dass man meine Tabellen sofort
überschauen kann und direkt versteht.

Danke für Eure Einschätzungen,

Daniel

Re: aussage...
 

Daniel Nemetz wrote:

[Telefonnummer und Email-Adresse zu Benutzertabelle
hinzufügen oder in getrennten Tabellen speichern]

> Danke für Eure Einschätzungen,

Wenn sicher ist, dass niemals mehr als eine Telefonnummer
und eine Email-Adresse je Benutzer gespeichert werden soll, ist es
einfacher, diese Information in die Benutzertabelle mit aufzunehmen.

Ansonsten ist es schlicht eine unkorrekte Modellierung.

Performance- und Speicherplatzfragen sind bei dieser Sache
m.E. vernachlässigbar.

Gruß
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: aussage...
 

Daniel Nemetz <daniel.nemetz@gmail.com> wrote:
> > 1. Sollte man darauf achten Tabellen immer in übersichtlichere
> Teiltabellen zu zerlegen.

Übersichtlich schon, aber nicht leer.

> > Dies verhindert auch das Risiko für anomalien.

Was auch immer eine Anomalie ist. Da hat er sich glaube etwas
zusammengesponnen.

> > 2. Der wichtigste Punkt:
> >
> > Nach deiner Methodik würde für jede Column eines Users in der nichts
> drinnen steht, trotzdem Speicherplatz reserviert werden der aber nicht
> genutzt wird. (z.B. verlangsamt das natürlich auch die DB-Operationen
> die Du auf diese Tabelle ausführst).

Das kommt zum einen auf den Datentyp an und zum anderen kommt es drauf an
wie oft er teilspalten oder alle spalten braucht. Wenn er naemlich mehrrere
Tabellen joined dann ist das ungleich ressourcenfressender als ein paar null
spalten. Zumal er dank Index sowieso kein Tablescan machen sollte.


> > Ich habe es mit einer vielzahl von möglichen Usern mit
> unterschiedlichen Eigenschaften zu tun.
> > Jeder User kann aber seine Eigenschaften verändern.

Gut das kann natuerlich Sinn machen wenn man ein Datennodell mit Vererbung
oder Customizing hat. Für die Hauptattribute macht es aber kenen Sinn, und
auch nicht bei Zusatztabellen mit 1-2 Attributen.

Gruss
Bernd

Re: aussage...
 

Daniel Nemetz wrote:
> Im folgenden möchte ich gern die Aussagen welche in einer welche mir
> gegenüber gemacht wurden zur Diekussion stellen.
>
> Die Aussage bezieht sich auf eine Datenbank in der ein Datensatz eines
> Users mit einer ID in einer Tabelle abgelegt wird, die eMail-Adresse und
> die Handynummer jeweils in einer eigenen, auch mit der ID um die
> Datensätze zu verbinden.
>
> Meiner Ansicht nach macht das nur Sinn, wenn man pro User mehrere
> eMail-Adresse oder Handynummern speichern will, mein Kontrahent nennt
> die folgenden Argumente:

Genauso ist es, es macht nur Sinn, wenn man mehrere Nummern, Adressen
usw. speichern will oder es vielleicht irgendwann mal vor hat.

Ansonsten ist dieses DB-Design nicht minimalisiert.

>
> > 1. Sollte man darauf achten Tabellen immer in übersichtlichere
> Teiltabellen zu zerlegen.
> > Dies verhindert auch das Risiko für anomalien.

Was für Anomalien hat er denn zu bieten?

> > 2. Der wichtigste Punkt:
> >
> > Nach deiner Methodik würde für jede Column eines Users in der nichts
> drinnen steht, trotzdem Speicherplatz reserviert werden der aber nicht
> genutzt wird. (z.B. verlangsamt das natürlich auch die DB-Operationen
> die Du auf diese Tabelle ausführst).

Das ist nur teilwar, wie schon von anderen hier gepostet.

> > Bei meinem Modell hingegen (welches nicht nur übersichtlicher &
> leichter zu pflegen ist) lege ich für jeden User nur die Datensätze (in
> den Tabellen an) an die er auch wirklich benötigt.
> >
> > Ich habe es mit einer vielzahl von möglichen Usern mit
> unterschiedlichen Eigenschaften zu tun.
> > Jeder User kann aber seine Eigenschaften verändern.
> >
> >

Nunja,
1. ist fraglich wie er bei 20 Eigenschaften die Performance erreichen
will, die er mit nur einer Tabelle hätte, wenn er alle Eigenschaften
haben will -->
2. will er alle Eigenschaften auf einmal abfragen geht das nicht so ohne
weiteres, wenn z.B. ein User keine Email hat, da muß schon ein Outer
Join oder Ähnliches her

> > Das mit dem Speicherplatz und der Performance ist im Gegensatz zu so
> Hobby-mysql Datenbanken z.B. kleinere bis mittlere Webshops für meine
> Datenmengen sehr entscheiden & machts sich durch die hohe Anzahl von
> "simultanen" DB-Zugriffen auch direkt bemerkbar.

Siehe jeder Menge Joins für jede Eigenschaft ;)

> >
> > Ein netter Nebeneffekt ist auch noch, dass man meine Tabellen sofort
> überschauen kann und direkt versteht.

und was ist nicht zu verstehen, wenn deine User-Tabelle ein Attribut
Email und ein Attribut Handynummer hat?

>
> Danke für Eure Einschätzungen,
>
> Daniel

Bis denn dann
Stefan

Re: aussage...
 

Hallo Daniel,

Daniel Nemetz meint:

> Die Aussage bezieht sich auf eine Datenbank in der ein
> Datensatz eines Users mit einer ID in einer Tabelle
> abgelegt wird, die eMail-Adresse und die Handynummer
> jeweils in einer eigenen, auch mit der ID um die
> Datensätze zu verbinden.
>
> Meiner Ansicht nach macht das nur Sinn, wenn man pro User
> mehrere eMail-Adresse oder Handynummern speichern will,
> mein Kontrahent nennt die folgenden Argumente:

.... womit Du IMHO gut liegst.

Ich persoenlich habe alledings immer meine nette Paranoia
parat, dass es nicht lange dauern wird, dann der Auftrageber
fragen wird "und wo schreibe ich die Festnetznummer rein?"
(soll heissen: ich rechne immer damit, dass sich am Ende die
Wuensche gegenueber den Urspruenglichen so um ca. 75%
aufblaehen)

> Sollte man darauf achten Tabellen immer in übersichtlichere
> Teiltabellen zu zerlegen.

korrekt ... aber wieviel ist "uebersichtlich"? 10 Spalten,
xy Byte pro Datensatz, ...?

> Dies verhindert auch das Risiko für anomalien.

Welche Anomalie tritt denn auf, wenn es lt. Anforderung
nur eine eMail-Adresse und eine Telefonnummer gibt?

Die Normaliesierung sollte aufgrund des Anforderungs-
katalogs bzw. deiner Befuerchtungen einer Erweiterung
ebendiesens und nicht aufgrund irgendeiner abstrakten
Ebene durchgefuehrt werden.

> Nach deiner Methodik würde für jede Column eines Users
> in der nichts drinnen steht, trotzdem Speicherplatz
> reserviert werden der aber nicht genutzt wird.

Da wuerde ich doch mal zurueckfragen, wie denn der
Zustand NULL (bei einer Zeichenfolge) intern von dem
DBMS dargestellt wird? Diese Behauptung habe ich schon
oft gehoert, aber beim nachfragen sind bisher alle ins
stottern gekommen. Ich gehe davon aus, dass maximal
der Pointer, der auf die Speicherstelle zeigen soll auf die
Speicherstelle 0 zeigt.

> (z.B. verlangsamt das natürlich auch die
> DB-Operationen die Du auf diese Tabelle ausführst).

Wieso denn das? Bei "SELECT * FROM t1 WHERE [...]"
kann ich mir ja noch vorstellen, dass das etwas ausmachen
koennte (habe aber sogar da meine Zweifel), aber wenn
immer nur die Felder abgerufen werden, die auch nur
benoetigt werden, duerfte die aufgeteilte Variante deutlich
hinterher sein, weil ja ein Join gemacht werden muss,
wenn die Handynummer gebraucht wird.

> Bei meinem Modell hingegen (welches nicht nur
> übersichtlicher & leichter zu pflegen ist)

Wenn die Limitierung "max. eine Telefonnummer"
so bleibt, empfinde ich das eher im Gegenteil.

> Ich habe es mit einer vielzahl von möglichen Usern mit
> unterschiedlichen Eigenschaften zu tun.
> Jeder User kann aber seine Eigenschaften verändern.

So langsam bekomme ich den Eindruck, dass bei ihm
_grundsaetzlich_ alle Tabelle aufgeteilt sind ... ungefaehr
so:

KundenTbl:
KundenID

KundenEigenschaftenTbl:
KundenID
EigenschaftID
EigenschaftsWert

ArtikelTbl:
ArtikelID

ArtikelEigenschaftenTbl:
ArtikelID
EigenschaftID
EigenschaftsWert

AuftragsKopfTbl:
AufKopfID

AuftragsEigenschaftenTbl:
AufKopfID
EigenschaftID
EigenschaftsWert

AuftragsPosTbl:
AufKopfID
AufPosID

AuftragsEigenschaftenTbl:
AufKopfID
AufPosID
EigenschaftID
EigenschaftsWert

(dabei gibt es dann auch noch Verbesserungs-
moeglichkeiten ;-))

> Das mit dem Speicherplatz und der Performance ist im
> Gegensatz zu so Hobby-mysql Datenbanken z.B. kleinere bis
> mittlere Webshops für meine Datenmengen sehr entscheiden
> & machts sich durch die hohe Anzahl von "simultanen"
> DB-Zugriffen auch direkt bemerkbar.

Hmmm ... und was ist mit Lese-Locks bei Joins, um die Daten
konsistent zurueck zu geben? Die duerften da wesentlich
gefaehrlicher sein.

> Ein netter Nebeneffekt ist auch noch, dass man meine
> Tabellen sofort überschauen kann und direkt versteht.

Denke ich nicht. Mir erschliesst es sich besser, wenn ich
die Daten in einem Datensatz stehen habe.

Es kommt aber auch auf die sichtweise an und was die
Anwendung mit den Daten tun soll.

Ich kann z. B. eMail und Handynummer als "Kontakt-
moeglichkeiten" ansehen. Dann haette wir eine Anomalie.

Aber auch erst wenn die Anwendung das so sieht. Z. B.
soll der Kunde automatische Nachrichten erhalten ...
vorzugsweise per SMS. Dann koennte bei der separaten
Tabelle ein

SELECT
KontaktTyp
, KontaktWert
FROM
KundenKontakt
WHERE
KundenID = 5
ORDER BY
KontaktTyp

Der erste Satz, ist dann die "Kontaktmethode", die benutzt
wird. Beim nicht aufgeteilen saehe das dann so aus:

<PSEUDOCODE>
SELECT
eMail
, HandyNummer
FROM
KundenTabelle

If (Not HandyNummer IS NULL) Then
SendeSMS
ElseIf (Not eMail IS NULL) Then
SendeEMail
End If
</PSEUDOCODE>

Wenn da jetzt noch ander Kontakt-Moeglichkeiten
hinzu kommen wuerden, ist das aufteilen deutlich
besser.

Daher frage dich selbst, ob es naheliegend ist, dass
"der Auftrageber" auf die Idee kommt die
Anforderung zu erweitern bzw. ob Du "Potenzial"
in dieser Richtung bei ihm erkannt hast.

Tschau
Ingo

Re: aussage...
 

Ingo Moch <myjunkmail.not_reading@gmx.de> wrote:
> Da wuerde ich doch mal zurueckfragen, wie denn der
> Zustand NULL (bei einer Zeichenfolge) intern von dem
> DBMS dargestellt wird? Diese Behauptung habe ich schon
> oft gehoert, aber beim nachfragen sind bisher alle ins
> stottern gekommen. Ich gehe davon aus, dass maximal
> der Pointer, der auf die Speicherstelle zeigen soll auf die
> Speicherstelle 0 zeigt.

Das kommt wie gesagt sehr auf das DB System und den Datentyp an, aber in
erster Näherung kann man davon ausgehen dass ein Null-bares Feld nur wenig
Byte belegt. Allerdings darf man nicht vergessen, dass nachträgliches
updaten von solchen Feldern in Sätzen dann eklich werden kann (der Datensatz
wächst).

Gruss
Bernd

Re: aussage...
 

Daniel Nemetz schrieb am 31.05.2005 in <3g3f17Faf432U1@uni-berlin.de>:

und bekam schon viele Antworten, hier noch meine:

Mit Sicherheit ist es sinnvoll, Telefonnummern/email etc in eine
separate Tabelle zu schreiben, wenn es mehrere bis viele davon gibt
(wegen der üblichen 3-4 verdächtigen
privat/geschäftlich/privatmobil/geschäftlichmobil würde ich mir aber
keinen hals machen und sie direkt in den DS schreiben)

Wenn aber sicher gestellt ist, daß des DS genügend Platz für alle
relevanten Einträge haben kann, dann ist eine weitere Tabelle wegen der
notwendigen JOINs m.E. unnötiger overhead.

Nehmen wir mal Telefonnummern: In Deutschland sind es m.E. 12 Ziffern,
sind wir einmal großzügig und sagen 20.
Zudem müßte ja in der Tabelle 2 noch eine Charakterisierung erfolgen, da
die implizite Zuordnung über die Spalten nicht funktioniert (mobil ...),
sagen wir also mal 1 byte.
Wir nehmen auch einmal an, daß auch alle 20 Zeichen belegt werden und
daß die ID, um die Datensätze zu verknüpfen 4 byte belegt.
Wenn wir jetzt von einer Datenbank mit 1 000 000 Adressen ausgehen,
80% 1 TelNr
60% 2 TelNr
40% 3 TelNr
20% 4 TelNr

dann macht das 2 000 000 x 25 byte = 50 000 000 byte ca. 50 MB

hättest Du die Nummern als eigene Spalten vorgesehen, dann wären das je
DS 100 byte also 100 000 000 byte ca. 100 MB

Wenn ich jetzt einmal annehme, daß ihr nicht bloß Telefonnummern (und
email- Adressen) speichert, sondern auch Nutzdaten, wie Name (25)
Vorname (25) Ort (25) PLZ (5) und zu jeder Adresse auch noch einige
Nutzdaten (Artikel, Datumse etc, alles zusammen 500)
dann sind es entweder 550 oder 600 MB, dieser Unterschied sollte m.E.
irrelevant sein.

Aber dieses tatsächlich einzuschätzen, das könnt am Ende nur ihr. (Fax-
Nummern, Lieferadressen, mehrere Wohnungen etc.)

HTH
Andreas

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

Re: aussage...
 

Frank Seitz schrieb:

> Wenn sicher ist, dass niemals mehr als eine Telefonnummer
> und eine Email-Adresse je Benutzer gespeichert werden soll, ist es
> einfacher, diese Information in die Benutzertabelle mit aufzunehmen.
>
> Ansonsten ist es schlicht eine unkorrekte Modellierung.
>
> Performance- und Speicherplatzfragen sind bei dieser Sache
> m.E. vernachlässigbar.

Das hängt starkt vom Umfang des Datenbestandes und der Organisation der
DB ab. Wobei mir derzeit nur DB bekannt sind die potenziellen
Speicherplatzbedarf im Datensatz gleich mit belegen/reservieren.

Mir sind solche Dinge allerdings auch schon mehrfach vor die Füsse
gefallen, ohne dass ich die Ursache verbockt hätte.

Ralf