Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation

[mkinzler]

Ob das in diesem Fall aber der beste Weg ist wage ich zu bezweifeln. Vor allem, da er von 1:n sprach (es sich anscheinend um kundenspezifische Erweiterungsfelder handelt). da könnten schon sehr viele weitere Spalten zusammenkommen.
Es gibt sicherlich Anwendungsbereiche, in denem man durch Verzicht auf Normalisierung enorme Performancegewinne bekommen kann ( von unbenutzbar zu fix), in den meisten Fällen aber nicht und die kleine Steigerung erkauft man sich sehr teuer durch die fehlende Flexibilität.

[Dejan Vu]

Na klar 1:n, was sonst?

Wieso weniger Flexibilität?
Wenn Du deine 3NF verwendest, fügst Du eine neue 'Spalte' so ein:

Code:

insert into Details (CustomerID,FlagID) values (12345,'X')

Wenn du alle Spalten in einer Tabelle hast, dann so (allerdings für alle Kunden):

Code:

ALTER TABLE Customer ADD 'FlagX' bit not null (0)

Entfernen analog. Wo ist da jetzt die fehlende Flexibilität?

Wie gesagt: Ich habe es genau so gemacht. Es ist *viel* einfacher so.

Das ist natürlich kein Plädoyer gegen Normalisierung, nur 'um jeden Preis' eben nicht.

Eine SQL-Datenbank mit 40000 Datensätzen, die jeweils ca. 150-200 Properties besitzen (unterschiedliche Produkte in einer Tabelle) und als EAVund modelliert war, ist performancetechnisch ziemlich in den Keller gegangen.

Gerade wenn es sehr viele optionale Daten werden, würde ich aufpassen und lieber den denormalisierten Ansatz nehmen. Oder -was eigentlich optimal wäre- die optionalen Felder gruppieren und die Gruppe dann als eigene Tabelle modellieren.

[p80286]

Zitat von mkinzler:

Es gibt sicherlich Anwendungsbereiche, in denem man durch Verzicht auf Normalisierung enorme Performancegewinne bekommen kann ( von unbenutzbar zu fix),

Damit züchtet man sich dann nahezu unwartbare Tabellenmonstren heran. Ich hab gute Erfahrungen mit "Extrem-Normalisierung" gemacht. Für Abfragen gibt es dann ein paar Views die die DB-Komplexität ganz gut verstecken.

Gruß
K-H

[Sir Rufo]

Zitat von p80286:

Damit züchtet man sich dann nahezu unwartbare Tabellenmonstren heran. Ich hab gute Erfahrungen mit "Extrem-Normalisierung" gemacht. Für Abfragen gibt es dann ein paar Views die die DB-Komplexität ganz gut verstecken.

Und wenn die Views zu komplex werden und dadurch das Erstellen der View zu lange dauert, dann erstellt man eine Tabelle, die dann wie die View genutzt wird (rein lesend).

[Jumpy]

Zitat von Sir Rufo:

Zitat von p80286:

Damit züchtet man sich dann nahezu unwartbare Tabellenmonstren heran. Ich hab gute Erfahrungen mit "Extrem-Normalisierung" gemacht. Für Abfragen gibt es dann ein paar Views die die DB-Komplexität ganz gut verstecken.

Und wenn die Views zu komplex werden und dadurch das Erstellen der View zu lange dauert, dann erstellt man eine Tabelle, die dann wie die View genutzt wird (rein lesend).

Wie machst du das dann in der Praxis? Wird diese Zusatztabelle gefüllt, wenn die eigentlichen Tabellen gefüllt werden? Mit triggern usw? Oder wird diese Tabelle alle Nase lang mal neu erstellt/aktualisiert?

[Aurelius]

Es ist natürlich richtig, dass man durch Normalisierung etc. Einbußen in der Performance bekommt. Allerdings nehme ich persönlich sowohl im Datenbankdesign als auch im Quelltext Peformanceverluste (sofern sie im Rahmen bleiben und es keine zeitkritische Anwendung ist) in Kauf, solange dadurch das System verständlich und leicht wartbar/erweiterbar bleibt.

[Sir Rufo]

Zitat von Jumpy:

Wie machst du das dann in der Praxis? Wird diese Zusatztabelle gefüllt, wenn die eigentlichen Tabellen gefüllt werden? Mit triggern usw? Oder wird diese Tabelle alle Nase lang mal neu erstellt/aktualisiert?

Ja ein Trigger, wenn es eine klassische Datenbank ist und es synchron erfolgen kann/soll.

Asynchron ist auch möglich nur halt von der Verwaltung etwas aufwändiger ... hält sich aber in Grenzen.

Wenn man mit einem EventStore arbeitet, dann wird das nur so gemacht - weil anders gar nicht möglich

[nahpets]

Zitat von Jumpy:

Zitat von Sir Rufo:

Und wenn die Views zu komplex werden und dadurch das Erstellen der View zu lange dauert, dann erstellt man eine Tabelle, die dann wie die View genutzt wird (rein lesend).

Wie machst du das dann in der Praxis? Wird diese Zusatztabelle gefüllt, wenn die eigentlichen Tabellen gefüllt werden? Mit triggern usw? Oder wird diese Tabelle alle Nase lang mal neu erstellt/aktualisiert?

Wir haben (wenn sowas tatsächlich erforderlich ist) dann entsprechende Prozesse, die zu definierten Zeitpunkten die vorhandene Tabelle wegwerfen und per

Code:

Create table as select * from a,b,c,d,e,... where a.id = b.id...

neu erstellen. Dahinter läuft dann ein entsprechendes Script für die Indexerstellung, Statistiken...
Ein Truncate Table mit anschließender Neubefüllung kann es natürlich auch tuen. Gerade bei sehr großen Datenmengen kann es aber deutlich schneller werden, wenn man eine "indexlose" Tabelle befüllt und die Indexerstellung erst nach der Befüllung vornimmt. Die Indexpflege beim Befüllen kann, je nach Datenmenge, auch schonmal (gefühlt) Wochen dauern.

Es kann aber auch passieren, dass von einem Programm die Tabelle geleert wird und dann vom Programm die "Basisdaten" in diese Tabelle geschrieben werden und nachfolgende Prozesse mit den "Basisdaten" dieser Tabelle (und ggfls. weiteren Tabellen) Berechnungen durchführen, um diese dann in weiteren Spalten der Tabellen abzulegen.
Weitere Prozesse können dann auf die hier abgelegten "Basisdaten" + "Zusatzdaten" zugreifen und ggfls. weiter Ergebnisse in weiteren Spalten ablegen.

In den Systemen, die ich habe kennenlernen dürfen, haben die kleineren Tabellen sowas um die 30 Mio. Sätze gehabt, die größeren um die 150 bis 200 Mio.

Aber die Regel, die einem klar sagt, wie man soetwas macht, gibt es eigentlich nicht. Es kommt doch sehr auf die Datenmenge, die "Eigenheiten" des genutzten Datenbanksystems und letztlich nicht unerheblich auf die Hardware an, auf der der "ganze Spaß" läuft.

Zitat von Aurelius:

Es ist natürlich richtig, dass man durch Normalisierung etc. Einbußen in der Performance bekommt. Allerdings nehme ich persönlich sowohl im Datenbankdesign als auch im Quelltext Peformanceverluste (sofern sie im Rahmen bleiben und es keine zeitkritische Anwendung ist) in Kauf, solange dadurch das System verständlich und leicht wartbar/erweiterbar bleibt.

Dies halte ich für eine wesentliche Aussage. Mir ist noch kein System "in Finger" gekommen, an dem Anwender im Dialog "live" gearbeitet haben und bei dem aus Performancegründen eine Denormalisierung erforderlich war. An eine gezielte Denormalisierung denke ich erst, wenn es darum geht, die Laufzeit von Wochen auf Tage zu reduzieren.
Auch wenn ich ggfls. auf denormalisierte Daten schneller zugreifen kann, als auf normalisierte Daten, so darf ich den (Zeit)Aufwand für die Denormalisierung und deren Konsistenzhaltung nicht vergessen.

Habe ich in einem System mit 40000, 50000 Kunden und den zugehörigen Nachschlagtabellen ein Performanceproblem, so habe ich sicherlich ein Problem, dass nicht durch Denormalisierung sinnvoll gelöst wird, sondern eventuell nur eine schlecht konfigurierte Datenbank oder eine umständliche und resourcenfressende Umsetzung der Geschäftslogik.

Viele Performanceprobleme, die ich habe lösen müssen, lagen weder an der Normalisierung der Daten, noch an der Hardware, sondern einfach nur an äußerst umständlicher Umsetzung von Abfragen.

[p80286]

Zitat von Sir Rufo:

Ja ein Trigger, wenn es eine klassische Datenbank ist und es synchron erfolgen kann/soll.

Asynchron ist auch möglich nur halt von der Verwaltung etwas aufwändiger ... hält sich aber in Grenzen.

Ich durfte auch einmal mit einer solchen Datenbank arbeiten. Da war die Synchronisierung zwischen DatenTabellen und ViewTabelle so "optimal" gelöst, daß jeden Monat eine Neuerstellung der ViewTabelle notwendig war.
"Kaum macht man's richtig - schon funktioniert's" aber wenn nicht.....

Gruß
K-H

P.S.
entweder lebe ich auf einer Insel der Glückseligen (Oracle), aber ich hatte bisher nie ernsthafte Performanceprobleme mit Views.
(der Kollege der MS-Fraktion in der Zwischenzeit auch nicht mehr)

[jobo]

Ja und der Glückselige verwendet am liebsten Snapshots (oder Materialized Views) und definiert, wie und wann sie aktualisiert werden sollen.
Mit konsequentem Einsatz von Views (und nach Bedarf SP) hat man sowieso eine Menge Freiheitsgrade, den eigenen oder fremden Bockmist geradezuziehen, ohne dass es die Anwendung stört. Jedenfalls wenn man sich explizit mit der DB-Serverschicht abgibt.