Re: Glossar(Stammdaten)
- From: Roland Kruggel <rkruggel@xxxxxxx>
- To: idefix@xxxxxxxxxxxxx
- Date: Wed, 18 Jun 2003 07:37:15 +0200
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?
closedArea
>
> >> 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.
>
> > 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
--
Roland Kruggel mailto: rkruggel@xxxxxxx
System: AMD 1200Mhz, Debian woody, 2.4.20, KDE 3.1
--
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:
