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:
Kunde Kundenummer, Name, .... Adresse Adr.-ID, Strasse, Nummer, Ort, PLZ, Land ... Kundadr. Kundennummer, Adr.-ID
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.
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.
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.
cu
-- 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
-- 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)
