Abschied

  • From: Heiko Kundlacz <heiko.kundlacz@xxxxxxxxxx>
  • To: idefix@xxxxxxxxxxxxx
  • Date: Wed, 18 Jun 2003 09:29:35 +0200

Roland Kruggel wrote:

Am Dienstag Juni 17 2003 22:59 schrieb Yevgen Reznichenko:


Am 06/17/2003 09:18 PM schrieb Roland Kruggel:


Was spricht gegen einen ID in jeder Tabelle?


1. Im Falle des Kunden, Lieferanten, Rechnung, Lieferschein usw.
müssen wir sowieso eine *eindeutige* Nummer erzeugen und diese in
den Tabellen ablegen was hat es denn für ein Sinn eine zusätzliche
ID einzuführen? Für die Referenzierung ist Kundennummer usw.
vollkommen ausreichend da diese eindeutig ist. Was soll das
bringen?


Falsch. Es wird zwar in der Adresstabelle eine Eindeutige Nummer
gespeichert, das ist aber die ID. Die Adressnummer, Kundennummer,
Lieferantennummer etc. wird nicht in der AdressTabelle gespeichert
sondern in einer separaten Tabelle. VErknüpft über die ID.


Kann das sein dass wir immernoch uns die Tabellen unterschiedlich
vorstellen? Mir schwingen vor den Augen:

Tabelle Attribute

Kunde Kundenummer, Name, ....
Adresse Adr.-ID, Strasse, Nummer, Ort, PLZ, Land ...
Kundadr. Kundennummer, Adr.-ID

usw.

Wie sieht deine Vorstellung von Tabellen?



3. Man erzeugt eine ID für eine Tabelle, wenn diese zu eindeutigen
Referenzierung benötigt wird. Ist eine bereits vorhanden (egal ob
nummerisch oder alphanummerisch) so wird diese eindeutige Referenz
genommen.


Die eindeutige Referenz ist die ID. Integer sind viel schneller als
char.


Siehe meine Antwort auf Michaels Mail



4. Zu der Aussage von Michael "der Overhead ist nicht so gross",
kann ich folgendes sagen: Overhead ist riesig! Tabellen im
normalisierten Zustand sind normalerweise 2 bis 5 Spalten gross,


Das werden wir nicht hinbekommen. Wir wollen uns ncht zu tode
Normaliesieren.


Ich weiss nicht mit welchen Tabellen du gearbeitet hast, aber ich
habe bis jetzt nur solche gesehen. Und die Normalisierung in die 3
Normalform muss schon sein.



nehmen wir nun die Mitte davon so bekommen wir 3,5 Spalten, die
wirklich benötigt werden, nun machen wir eine Spalte hinzu und
bekommen 4,5 Spalten im Durchschnitt! Ist es viel? Na, wenn man
sich DB im Bereich von 2 GB (und das sind die kleinen) anguckt so
mussten an deren Stelle nur durch die Hinzufügung von zusätzlicher
Spalte 2,57GB her, d.h. 570 MB umsonst! Ausserdem muss diese ID
von der DB verwaltet und erzeugt werden! Wozu dann der Aufwand,
wenn wir sowieso eine eindeutige Kundenummer, Lieferantennummer,
Rechnungsnummer, Lieferscheinnummer usw. haben?


Sag mir doch mal bitte, da wir gerade am rechnen sind, wieviel
Adressen werden in deiner Tabellen mit 2,57GB gespeicher?

Du wirst auf einen Wert kommen den wir mit unserem System
warscheinlich nicht erreichen werden.


Warum? Das sind ganz realistische Werte, du darfst nicht vergessen
dass nicht nur die Werte abgelegt werden müssen sondern auch Ihre
Spezifikationen, Einschränkungen, Wertebreiche usw. Ausserdem wollen
wir doch nicht nur Adressen speichern.



Zum anderen ob unsere Datenbank nun 2,5GB oder 3GB oder 5GB gr0ß
wird, ist unerheblich. a) Mysql ist für solche größen durchaus
ausgelegt.


Davon habe ich noch nichts gelesen, jedoch die Grösse von 2,57GB
anstelle von 2 GB bedeutet dass unnötig viele Daten mitverwaltet
werden und diese müssen bei jeder Abfrage mitgeschleppt werden. Was
sehr in die Performance drückt.



Noch eine Berechnung
Wenn wir davon ausgehen das der User 25.000 AdressDaten gespeichert hat, und wir 8 Tabellen für die Adressenverwaltung benötigen, sieht die Rechnung folgender massen aus.

25.000 * 4Byte = 100.000 Byte * 8 Tabellen = 800.000 Byte / 1024 = 781,25 KB

Speicherplatz?



b) Die Geschwindigkeit ist auch bei diesen Größen sehr gut.


Nein. Bei der Geschwindigkeit kommt es nicht so sehr auf die
wirkliche DB grösse an, sondern in wieweit diese optimiert für die
Anfragen ist. Die Optimierung fängt schon bei der Erstellung von
Tabellen an! Wir Diskutieren momentan nicht einmal um Optimierung
sondern um
Deoptimierung! Und wenn wir so oft auf die Kundennummer zugreifen
sollten so legt man einen Index auf diese an um die Abfragezeit zu
beschleunigen.



c) Plattenplatz kostet nichts mehr.


Oh doch, vielleicht auf der Festplatte nicht viel, aber bei den
Backups schon.



Wie gesagt ich möchte nicht abstreiten dass in manchen Fällen es
durch aus sinnvoll diese Nummer zu erzeugen nur weit nicht in
allen.


Richtig. Nicht in allen.


Jetzt verstehe ich etwas nicht, was ist nun in _JEDE_ oder "Nicht in
allen"



Aber wenn wir das system erweitern müssen/wollen und wir brauchen
eine neue Tabelle kann es sehr vorteil sein eine ID zu haben um sie
zu verknüpfen.


Erstens, soweit ich weiss bittet DB eigene Mechanismen dafür um das
statisch zu machen. Zweitens, wird eine neu Tabelle aus schon
vorhanden benötigt so kann man immer einen VIEW erstellen. Und
drittens warum kann zu dieser Referenzierung nicht die Kundennummer
(oder was anderes) herangezogen werden?



cu


Yevgen.

--
Please do *not* send "Security Patch Notifications" or "Security
Updates"; this system isn't running a Micro$oft operating system.
And don't annoy me <mailto:postmaster@[127.0.0.1]> please :-D



cu



Guten Tag zusammen,

ich moechte mich von dieser Liste verabschieden und wuensche euch viel Glueck. Mir ist das ganze doch etwas zu DB-lastig.

Heiko

--
Projekt: Warenwirtschaft. Projektname: Jana
Infos: http://jana.bbf7.de

--------------------------------------------------------------------
Zum AUSTRAGEN schicken Sie eine Mail an idefix-request@xxxxxxxxxxxxx
mit dem Subject "unsubscribe". 
mailto:idefix-request@xxxxxxxxxxxxx?subject=unsubscribe

Mailarchive: //www.freelists.org/archives/idefix
Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)

Other related posts:

  • » Abschied
  1. Home
  2. idefix
  3. Archive
  4. 06-2003