Re: Glossar(Stammdaten)

Ok, hier mal ein Kompromissvorschlag. Was haltet ihr davon, jeder Tabelle eine obligatorische Integer Id zu verpassen. Wenn sich herausstellen sollte, dass es zuviel Overhead ist und sich negativ auswirkt, dann können wir die Spalten, die wirklich nicht gebraucht werden ja entfernen. Ansonsten haben wir halt eine Spalte zuviel, die uns bei einer eventuellen Erweiterung des Systems gute Dienste Leisten kann.

MfG
Michael

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



--
/* Fuck me gently with a chainsaw... */
        2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c

--
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: http://www.freelists.org/archives/idefix
Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)

Other related posts: