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

[Aurelius]

Hallo zusammen,

ich habe eine prinzipielle Frage zum Datenbank-Design und hätte da gerne ein paar Drittmeinungen.

Ich habe eine Tabelle, bspw. KUNDEN (alle Bezeichnungen sind nur Beispiele). Nun möchte ich für jeden Datensatz verschiedene Boolean-Steuerinformationen hinterlegen, welche Auswirkungen in diversen anderen Programmteilen haben (bspw. VIPKUNDE, KOMMUNIKATIONSSPERRE, MAHNSPERRE...). Klassischerweise ist das eine 1:1-Beziehung, ergo kann ich diese Daten direkt in der Tabelle KUNDEN hinterlegen.

Nun habe ich aber nicht nur einige wenige solcher Steuerinformationen, sondern einen ganzen Haufen voll. Im Laufe der Zeit kommen auf Kundenwunsch diverse andere Felder hinzu. Die Tabelle erhält somit immer mehr Felder und wird irgendwann unübersichtlich. Zusätzlich muss ich jedesmal die Oberfläche anfassen und die Felder zur Verfügung stellen.

Eine Alternative wäre, aus diesen Steuerinformationen einfach eine 1:n-Beziehung zu erstellen. Neue Tabelle KUNDENSTEUERINFORMATION mit den Spalten BEZECHNUNG und TYP (enthält per Enum die möglichen Informationen) und dazu eine Mapping-Tabelle KUNDEN_STEUERINFORMATIONEN_ZUORDNUNG. Bei einer entsprechend designten Oberfläche kann ich die Informationen nun vergleichsweise einfach (dynamisch) erweitern, zusätzlich blähe ich meine Haupttabelle nicht unnötig auf.

Was ist eure Meinung zu dieser Problematik? Laut Normalformen würden ja beide Varianten funktionieren.

[mkinzler]

Da es sich um eine n:m-Beziehung handelt würde ich das durch 3 Tabellen Lösen:

KUNDEN
ID
...

STATUS
ID
BEZ
...

KUNDENSTATI
ID
KundeID
STATUSID
Aktiv

[jobo]

Kann ich nur empfehlen. Ich würde allerdings noch etwas in die Datenhaltung investieren und die Infos ggF als XML Schnippsel inkl. XSD anlegen. Damit hast Du dann noch komfortable Möglichkeiten, die Eingabe zu validieren.

[mkinzler]

Zitat:

Laut Normalformen würden ja beide Varianten funktionieren.

Beim ersten Fall aber nur die 1.

[Mavarik]

OK! Old School...Auch auf die Gefahr hin, dass die Datenbank Freaks über mich herfallen...

Ich stehe oft vor der gleichen Frage...

Historisch gesehen habe ich es immer so gemacht, dass mein Record auf die nächste 2er Potenz verlängert habe.

Delphi-Quellcode:

Kunden = Record
           Name : String[40];
           ...
           Frei : Array[1024-(650+Sizeof(Whatever))] of Byte;
         end;

So konnte ich immer sehr schön Sektororientiert auf die Platte schreiben.

Das Konzept habe ich beibehalten.

Meine Datenbanken haben am Ende immer ein Blobfeld. Hier schreibe ich - wenn ich es brauche - gezipt erweiterte Information rein.
(Unter der Voraussetzung, dass ich diese nicht für ein Select,Sort usw. benötige)

Hab mir einfach eine generelle Routine dafür geschrieben... Fertig... Erweiterungen kein Thema...

Daher bin ich für Änderungen immer offen.

Zum Redesign Deiner Anwendung:

Ich Redesigne in so einem Fall IMMER... Die alternative wäre die Informationen in einem Grid darzustellen...
Das ist für mich ein absolutes NOGO... Nur Listen gehören in ein Grids... Nie Eingaben.

Mavarik

[Aurelius]

@ mkinzler:
Genau so einen Aufbau mit 3 Tabellen habe ich gemeint.
Aber bist du dir sicher dass die erste Variante die 2. Normalform etc. verletzt? Schließlich sind die Steuerinformationen ja nur abhängig vom Primary Key.

ID	Name	...	VIPKUNDE	MAHNSPERRE
1	Müller	...	1	0
2	Maier	...	0	0
3	Werner	...	1	1

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar :)

@ all: Danke für die Rückmeldungen :)

[Mavarik]

Zitat:

Zitat von Aurelius (Beitrag 1313707)

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar :)

Verteile Tabelle sind wie verteilte Datei...

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...
Eine Exception an der falschen Stellen... (Ja es gibt Transaktionen...)

Ein User kopiert eine Datei von a noch b oder nur eine Tabelle...

Alles unnötige Fehlerquellen - Einfach meine Erfahrung der letzten 34 Jahre Programmierung.

Eingabe in einem Grid? Vielleicht Deine..., aber meine Kunden können da nicht mit umgehen.

Die brauchen

Label: Edit
[ ] Checkcaption
Combobox [Speedbutton]

[&Speichern] [&Abbrechen]

Und nicht etwa ein DBNavigator mit Post & Refresh...

[DeddyH]

Zitat:

Zitat von Mavarik (Beitrag 1313709)

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht worden, damit so etwas nicht passieren kann.

[jobo]

@Aurelius: Hast Du im Arbeitsvertrag stehen, dass Du niemals die Normalform verletzen darfst? ;)
So eine Diskussion ist auf dieser Ebene m.E. müßig, bzw. gibt es bei Deiner Idee wichtigere Fragen. Wieviele Systeme gibt es, die bspw. explizit PLZ und Stadt abspeichern?
U.a. kann man sich vielleicht streiten, ob die Relationstabelle einen eigenständigen Primärschlüssel bekommt, wie vorgeschlagen oder ob die beiden Fremdschlüssel reichen, m.E. Geschmackssache.

Dymamische Anzeige/ Eingabe ist eine reine Kosten / Nutzen Geschichte. Wenn der Kunde zahlt, machst Du das Feld eben in die Maske rein. Wenn Du keine Lust und oder keine Zeit hast, obwohl der Kunde zahlt, tja..
Aber dann gibt es da Dinge, die würde ich von Fall zu Fall genau überlegen.

Beispiel Mahnsperre: Es kommt mir so vor, als ob das eine relativ zentrale Bedeutung für den ein oder anderen Business Case hat und das würde ich nicht unbedingt irgendwo unter ferner liefen abfackeln.
Oder anders: Wenn es um Inhalte geht, die meine eigene Anwendung nutzt, auswertet und sich jenachdem anders verhält, würde ich eine hohe Bindung an die Kernobjekte bevorzugen.
Sind es dagegen "irgendwelche" Kundendaten, die vielleicht sogar selbst beim Kunden nur importiert werden, nie oder selten angefasst werden und nur für einen weiteren DL gehalten und dann exportiert werden, würde ich das sehr gern "weiter weg" lagern.

[jobo]

Zitat:

Zitat von DeddyH (Beitrag 1313711)

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht
worden, damit so etwas nicht passieren kann.

Vermutlich hat er das. Ich habe ihn so verstanden, dass es ein allgemeiner Beitrag zu seinen schlechten Erfahrungen war.
Aber Du hast Recht, letzlich dürfte genau das "beim Update vergessen" mit einem richtigen DM bei redundanzfreier Datenhaltung nicht passieren.

[Mavarik]

Zitat:

Zitat von jobo (Beitrag 1313713)

Aber Du hast Recht, letzlich dürfte genau das "beim Update vergessen" mit einem richtigen DM bei redundanzfreier Datenhaltung nicht passieren.

Gerade da... Nicht den bösen User vergessen, der per Restore Zwei verschiedene Versionsstände zurückspielt...
Bei einer Tabelle kann Dir das nicht passieren...

Redundanzen sind Supi... Dann kann ich bei einem Datenverlust alles wieder herstellen... Beste Beispiel ist ein Neu & Änderungsjournal.

Eine Inkonsistenz wurde festgestellt... Kein Thema zurück zu letzten bekannten Version und ab da das Journal nochmal loslassen...

Jede Datenbank kennt Ihren aktuellen Journalstand? Bingo - Der böse User hat was falsches Kopiert... Total egal... Das System ist selbstheilend durch Redundanz...

Mavarik

PS.: So macht es meine Software auch... Nur die Exe noch auf der Platte - Kein Thema schwupdiWup alle RTF Files und alle anderen Dateien und Unterverzeichnisse sind wieder da... Wer braucht noch Installationsprogramme... :-)

[DeddyH]

Reden wir jetzt wirklich von Datenbanken oder von irgendwelchem selbstgestrickten Record-Geraffel? In "richtigen" DBMS geht es nämlich eher darum, Redundanzen zu vermeiden, um Inkonsistenzen auszuschließen.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1313721)

Reden wir jetzt wirklich von Datenbanken oder von irgendwelchem selbstgestrickten Record-Geraffel? In "richtigen" DBMS geht es nämlich eher darum, Redundanzen zu vermeiden, um Inkonsistenzen auszuschließen.

Nun ja ... so ganz nun auch wieder nicht ;)

In den richtigen Systemen unterscheidet man Read- und Write-Model. Das Write-Model ist die Wahrheit und das Read-Model ist eine Projektion dieser Wahrheit.

Warum? Weil es in den meisten Systemen mehr Lese- als Schreibzugriffe gibt. Und mit den richtigen Read-Modellen kann man die Last einer Datenbank erheblich verringern, weil eben keine JOINS benötigt werden.

Das Write-Model ist aber auf jeden Fall nicht redundant.

[jobo]

Zitat:

Zitat von DeddyH (Beitrag 1313721)

Reden wir jetzt wirklich von Datenbanken ..

Also selbst bei Records halte ich Redundanzen für unpraktisch bzw. kritisch. Und ja, ich habe von Datenbanken geredet und spreche aber von Redundanzen im Sinne der Normalform (wie im Negativ Beispiel angeführt PLZ>Ort).

Ein Logsystem, welches Werteänderungen mitschreibt setze ich auch ein, wie sicher auch viele andere, aber das ist vollkommen autark und in keiner Weise logisch in die Datenverarbeitung involviert, nicht mal transaktional, was man ja sonst idR auch gerne hat bei einem RDBMS, sonst wäre es größtenteils sinnlos.

Dass so ein Log ggF. bei einem Recoveryproblem o.ä. helfen kann, ist klar, dafür wurde es ja u.U. aufgebaut.
Ein solches Log hat aber mit der NF nichts zu tun.

[jobo]

@Sir Rufo
Es war aber von Datenmodell und Haltung die Rede, nicht von Transport und Darstellung oder?

[frankyboy1974]

Hallo,

die meisten Programmierer kennen die ersten drei Normalformen, tatsächlich hat Codd aber wesentlich mehr Normalformen veröffentlicht. Ich würde deswegen raten, das Problem verstößt gegen die 25. Normalform.:-D

mfg

[Sir Rufo]

Zitat:

Zitat von jobo (Beitrag 1313727)

@Sir Rufo
Es war aber von Datenmodell und Haltung die Rede, nicht von Transport und Darstellung oder?

Jepp, Read- und Write-Model liegen ja auch in dem/einem DBMS. Mit dem Transport oder der Darstellung hat das nichts zu tun - ausser, dass sich das Read-Model daran orientiert, was nachher in der Darstellung benötigt wird.

[Aurelius]

Zitat:

Zitat von jobo (Beitrag 1313712)

@Aurelius: Hast Du im Arbeitsvertrag stehen, dass Du niemals die Normalform verletzen darfst? ;)

Meine Rückfrage war eher Interessenshalber, da ich dort keine Verletzung erkennen kann. :) Aber allgemein versuche ich die Datenbank so "perfekt" wie möglich zu halten. Macht es einfacher eine schöne Anwendung darum zu stricken und gibt mir ein gutes Gefühl :angel:

Zitat:

Oder anders: Wenn es um Inhalte geht, die meine eigene Anwendung nutzt, auswertet und sich jenachdem anders verhält, würde ich eine hohe Bindung an die Kernobjekte bevorzugen.
Sind es dagegen "irgendwelche" Kundendaten, die vielleicht sogar selbst beim Kunden nur importiert werden, nie oder selten angefasst werden und nur für einen weiteren DL gehalten und dann exportiert werden, würde ich das sehr gern "weiter weg" lagern.

Gefällt mir :thumb:

[Dejan Vu]

Wenn man nicht aufpasst, hat vor lauter 3NF die Performance außen vor gelassen. Dem RDMBS ist es i.a. egal, ob man nun 10 oder 50 bit-Spalten pro Datensatz hat. Na ja, zumindest ist das bei SQL-Server so.

Also, ich würde mir das 2x überlegen, ob ich die Optionen wirklich alle einzeln in einer Detailtabelle vorhalten würde.

Es kann ja sein, das man das gruppieren kann. Oder einfach doch 100 Bit-Spalten in die Tabelle klatschen. Von der Performance her ist das jedenfalls bei weitem das Beste.

Ich habe Anwendungen, bei denen der Kunde solch optionale Spalten selber deklariert und die Anwendung im Hintergrund die Tabelle per ALTER TABLE einfach entsprechend updatet.

Man muss imho beim DB-Design immer Einfachheit, Performance und Normalform in Einklang bringen.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1313771)

Es kann ja sein, das man das gruppieren kann. Oder einfach doch 100 Bit-Spalten in die Tabelle klatschen. Von der Performance her ist das jedenfalls bei weitem das Beste.

Kann ich ausdrücklich bestätigen, zumindest für alle Fälle, in denen die DB große bis riesengroße Datenmengen vorhält. In meiner OSM-Verwaltung (OpenStreetMap) hatte ich anfangs auch erst versucht, wie aus dem Lehrbuch alle Redundanzen weitgehend zu vermeiden – mit dem Ergebnis, daß Abfragen inakzeptabel lange benötigten. Nachdem ich die Normalisierung wieder soweit rückgängig gemacht hatte, daß in der Tabelle für Orte (Millionen von Datensätzen) die Bundesländer, Länder, Provinzen etc. als String verfügbar waren und nicht mehr als Verweis auf die jeweiligen Sub-Tabellen BUNDESLAND, LAND, PROVINZ etc., bewegten sich die Abfragezeiten wieder in erträglichem Rahmen.

[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? :gruebel:

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:

Zitat von mkinzler (Beitrag 1313777)

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:

Zitat von p80286 (Beitrag 1313795)

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:

Zitat von Sir Rufo (Beitrag 1313799)

Zitat:

Zitat von p80286 (Beitrag 1313795)

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:

Zitat von Jumpy (Beitrag 1313804)

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:

Zitat von Jumpy (Beitrag 1313804)

Zitat:

Zitat von Sir Rufo (Beitrag 1313799)

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:

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:

Zitat von Sir Rufo (Beitrag 1313806)

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.

[Dejan Vu]

Zitat:

Zitat von nahpets (Beitrag 1313807)

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.

Ich habe mal blöderweise ein EAV-Antipattern eingesetzt (ich dachte damals, ich wäre der Größte :oops:). Alles perfekt: 5 Tabellen, um alles darstellen zu können. Nur: Die Antwortzeiten waren nicht hinnehmbar. Ich habe eine weitere Anwendung mit wenigen Mio Datensätzen, welches beim 10.Join in die Knie geht.

Das ist aber -muss ich zugeben- schon eine Weile her. Heute packt man einfach ein paar GB mehr RAM in den Server und dann läuft der. Außerdem lässt sich durch gutes DB-Design (Partitioning) sehr viel erreichen.

Trotzdem bin ich bei Produktionsdaten und der 3NF mittlerweile eher pragmatisch und verstecke mein Design hinter virtuellen Tabellen und/oder SP. So kann ich mein echtes DB-Design anpassen, wie ich lustig bin.

[nahpets]

@Dejan Vu
Klingt sehr vernünftig. "Das" richtige Vorgehen gibt es nicht, die Theorie mag noch so perfekt sein, wenn die Realität das nicht mit vertretbarem Aufwand abwickeln kann, muss eine pragmatische Lösung für den Einzelfall her.

Wer lange genug in dem Umfeld arbeitet, hat irgendwann seinen Erfahrungsschatz oder kennt jemanden mit dem Erfahrungsschatz für Problem X, jemanden für Problem Y... und dann wird (unter Zuhilfenahme von Creativität und einer gewissen Verspieltheit) die bestmögliche (umsetzbare und bezahlbare) Lösung gesucht.

Habe mal ein System neubauen müssen, dass vorher mit ausgereifter Software von der Analyse bis zur Implementierung (die von den Werkzeugen generiert wurde - sowohl Datenbank, als auch Programm), nach allen Regeln der Kunst erstellt wurde.
Das war seinerzeit die "Innovation" (seit dem hasse ich dieses Wort).
Preformance für die Tonne und als die "bekloppten Anwender" ein Feature haben wollten, dass diese Systeme nicht abbilden konnten, war es nicht möglich, die passenden Änderungen in den generierten Quelltext einzubauen.

Also Delphi genommen, Erfahrungsschatz dazu und vier Wochen fast ununterbrochen gearbeitet. Und dann war das fertig, pfleg- und wartbar und sauschnell.

PS.:
Schlecht implementierte Abfragen werden durch viel RAM nicht besser, sondern man verdrängt das Problem, bis das Mehr an Speicher irgendwann auch nicht mehr ausreicht (und der Zeitpunkt kommt immer, meist dann, wenn man nicht damit rechnet oder es extrem ungünstig ist - halt Murphy).

Unser o. g. Performanceprobleme hatten wir auf einem Datenbankhobel mit "nur" 64 CPUs und ich weiß nicht mehr 256 oder 512 GB Speicher. Ist fast ein Jahrzehnt her...

[Dejan Vu]

Wenn der Server den Index komplett im RAM halten will, der RAM aber zu knapp bemessen ist, hat das imho nichts mit 'schlechtem Design' zu tun (na, vielleicht doch nur ich komm nicht drauf). Da knallt man dann 32GB rein und fertig.

Aber natürlich: Ein Tablescan beibt ein Tablescan.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1313828)

Schlecht implementierte Abfragen werden durch viel RAM nicht besser, sondern man verdrängt das Problem, bis das Mehr an Speicher irgendwann auch nicht mehr ausreicht (und der Zeitpunkt kommt immer, meist dann, wenn man nicht damit rechnet oder es extrem ungünstig ist - halt Murphy).

Wenn schon das Datendesign nicht stimmt, bist Du noch schlimmer dran. Stell Dir vor 10 Adressfelder (ADR1..ADR10) und da mußt Du Orte suchen.
(Durch Augenschein in einem professionellen System bestätigt)

Gruß
K-H

[nahpets]

Zitat:

Zitat von Dejan Vu (Beitrag 1313839)

Wenn der Server den Index komplett im RAM halten will, der RAM aber zu knapp bemessen ist, hat das imho nichts mit 'schlechtem Design' zu tun (na, vielleicht doch nur ich komm nicht drauf). Da knallt man dann 32GB rein und fertig.

Aber natürlich: Ein Tablescan beibt ein Tablescan.

Ersteres: Stimmt natürlich (meistens), die Hardware muss in der Lage sein, die gestellte Aufgabe zu erledigen.

Zweiteres: Genau hier kann man extrem unperformant arbeiten.
Durch geschickte Umformulierung kann man der Datenbank dabei helfen, die Ergebnismenge von Beginn an möglichst klein zu halten. Weiß nicht, wie oft ich aus der Produktion gehört habe, dass ein Programm soundoslange lief und dann abbrach, weil der Temptablespace mal wieder voll war. Hier schreibt die Datenbank dann halt viel auf die Platte (weil halt ggfls. mal die maximal mögliche Speichermenge in der Hardware steckt) und das ist nun mal nicht der schnellste Weg. Wenn man ihr aber dabei hilft, die Datenmenge von vorneherein klein zu halten, dann spart man da auch sehr viele Plattenzugriffe.

Nehmen wir folgendes Beispiel:

Code:

select * from a, b, c, d, e
where a.id   = b.id
and   b.xid  = c.id
and   c.yid  = d.id
and   d.zid  = e.id
and   a.wert = 4

Hier geht die Datenbank her und baut alle Daten über die ID's zusammen und schränkt dann die Ergebnismenge dahingehend ein, dass nur die Sätze übrig bleiben, bei der in a der Wert = 4 ist.

Wenn man das Statement nun so umstellt:

Code:

select * from b, c, d, e, 
(select id from a where wert = 4) x
where x.id   = b.id
and   b.xid  = c.id
and   c.yid  = d.id
and   d.zid  = e.id

so kann die Datenbank zuerst die Teilmenge bilden, die die Einschränkung enthält und muss dann aus den anderen Tabellen nur noch die Datensätze zur Ergebnismenge zusammenstellen, die zur einschränkenden Teilmenge gehören.
Und ist das eine Einschränkung auf vielleicht mal 10% oder gar weniger, so kann man hier deutliche Laufzeitunterschiede ausmachen.

So erlebt bei einer Oracle-Datenbank mit insgesamt in dieser Konstellation ca. 300 Mio Datensätzen, resultierend aus der Tabellenverknüpfung ohne die Einschränkung auf Wert = 4. Natürlich waren die Bedingungen deutlich komplizierter, aber vom Prinzip her war es so. Und den * ersetze man bitte immer durch die benötigten Spalten, auch wenn man dann mal viel schreiben muss. Jede selektierte, aber nicht benötigte Spalte, belegt nur unnütz Speicher und/oder Plattenplatz.

Andere Datenbanken mögen sich da vollkommen anders verhalten, daher lässt sich "Das richtige Vorgehen" nicht generalisieren.

Zitat:

Zitat von p80286

Wenn schon das Datendesign nicht stimmt, bist Du noch schlimmer dran. Stell Dir vor 10 Adressfelder (ADR1..ADR10) und da mußt Du Orte suchen.

und das dann auch noch mit like '%ORTSNAME%'. Hatten wir hier doch kürzlich noch irgendwo in 'nem Thread.

Zitat:

Zitat von p80286

(Durch Augenschein in einem professionellen System bestätigt)

Aber das professionell ist hier doch hoffentlich ironisch gemeint. Es war doch wohl eher ein System, für das man bezahlen muss ;-)

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1313846)

Wenn man das Statement nun so umstellt:

Code:

select * from b, c, d, e, 
(select id from a where wert = 4) x
where x.id   = b.id
and   b.xid  = c.id
and   c.yid  = d.id
and   d.zid  = e.id

so kann die Datenbank zuerst die Teilmenge bilden, die die Einschränkung enthält und muss dann aus den anderen Tabellen nur noch die Datensätze zur Ergebnismenge zusammenstellen, die zur einschränkenden Teilmenge gehören.
Und ist das eine Einschränkung auf vielleicht mal 10% oder gar weniger, so kann man hier deutliche Laufzeitunterschiede ausmachen.

Eine Alternative wäre auch

Code:

select * 
from a join b on (a.xid=b.id and a.wert=4)
       join c on (b.xid=c.id)
       join d on (c.yid=d.id)
       join e on (d.zid=e.id)

(ist allerdings von der DB abhängig)

Zitat:

Zitat von nahpets (Beitrag 1313846)

Aber das professionell ist hier doch hoffentlich ironisch gemeint. Es war doch wohl eher ein System, für das man bezahlen muss ;-)

Ich werd' der Selbsteinschätzung des Herstellers doch nicht widersprechen:stupid:

Gruß
K-H

[jobo]

Zitat:

Zitat von nahpets (Beitrag 1313846)

Nehmen wir folgendes Beispiel...

Die Überlegungen, die hier angestellt werden, würde ich heutzutage eher im Bereich Legendenbildung ansiedeln.
Konkret stammt das beschriebene Verhalten vielleicht von einer Oracle DB 7, 8, max 9 mit RBO oder einem neueren System, das per Schalter abwärtskompatibel eingestellt ist.

Generell sollte heute jedes System, das Statistiken beherrscht, eine solche Aufgabe sinnvoll lösen. Und zwar nicht mittels Mutmaßung, es könnte sich um 10% Einschränkung handeln. Auch wenn eine Bedingung "id=4" sehr selektiv aussieht- man könnte ja sogar fast denken, es sei ein Primärschlüssel mit Top Einschränkung =100%- es kann genausogut eine vollkommen wirkungslose Einschränkung sein, weil einer der anderen Joins ggF. gegen einen einzigen Datensatz läuft und id=4 für den gesamten Rest gilt.
Die Systemstatistiken sollten da helfen.

Also auch wenn es das alles mal gab und in entsprechend alten Systemen immernoch gibt. Aktuell sollte man bei der Formulierung von SQL Statements durchaus unbefangen vorgehen, zumindest bevor man Annahmen trifft, die nicht (mehr) stimmen.
Ausnahme wäre, man arbeitet gezielt an einem alten Oracle 7 oder 8. Dann besser die 20(oder 15?) Regeln des RBO durchlesen und befolgen. Bei anderen Systemen entsprechend.

Am Ende bleiben dann vielleicht ein paar Prozent problematischer Abfragenfälle, die etwas Forschung benötigen, einen gezielten Optimzer Hint oder vielleicht sogar eine Denormalisierung des DM.

[nahpets]

Zitat:

Zitat von jobo (Beitrag 1313852)

Zitat:

Zitat von nahpets (Beitrag 1313846)

Nehmen wir folgendes Beispiel...

Die Überlegungen, die hier angestellt werden, würde ich heutzutage eher im Bereich Legendenbildung ansiedeln.
Konkret stammt das beschriebene Verhalten vielleicht von einer Oracle DB 7, 8, max 9 mit RBO oder einem neueren System, das per Schalter abwärtskompatibel eingestellt ist.

Stimmt, ist fast ein Jahrzehnt her und war Oracle 8.

Grundsätzlich gehe ich immer her und schaue zuerst, wie bekomme ich mit einem lesbaren Statement mein Ergebnis, auf Performance... wird erstmal nicht geachtet, sondern auf eine möglichst einfache und korrekte Abbildung der fachlichen Anforderung. Das hat Priorität. Rumexperimentiert wird erst dann, wenn aktuelle Statistiken... nicht mehr helfen und man einen anderen Weg suchen muss, weil der einfachste Weg nicht auf vertretbare Weise zum Ziel führt. Klimmzüge erst dann, wenn es anders nicht geht.

Zitat:

Zitat von jobo (Beitrag 1313852)

Generell sollte heute jedes System, das Statistiken beherrscht, eine solche Aufgabe sinnvoll lösen. Und zwar nicht mittels Mutmaßung, es könnte sich um 10% Einschränkung handeln. Auch wenn eine Bedingung "id=4" sehr selektiv aussieht- man könnte ja sogar fast denken, es sei ein Primärschlüssel mit Top Einschränkung =100%- es kann genausogut eine vollkommen wirkungslose Einschränkung sein, weil einer der anderen Joins ggF. gegen einen einzigen Datensatz läuft und id=4 für den gesamten Rest gilt.

id=4 hat ja erstmal überhaupt keine Aussage, id könnte ja auch immer 4 sein, also ein über die gesamte Tabelle geltender, konstanter Wert. Dann hilft das hier natürlich nichts. Die Einschränkung mit id=4 war hier nur beispielhaft gemeint, in der konkreten Situtation wurde die Tabelle mit dem kleinsten Volumen auf ca. 3% der enthaltenen Datenmenge eingeschränkt, mit dem Resultat, dass in dem konkreten Fall auch die übrigen Tabellen auf eine ähnliche Teilmenge eingeschränkt werden konnten. Der Optimiser hat das da halt beim ursprünglichen Statement irgendwie nicht hinbekommen. (Egal, ist Schnee von vorgestern.)

Zitat:

Zitat von jobo (Beitrag 1313852)

Die Systemstatistiken sollten da helfen.

Also auch wenn es das alles mal gab und in entsprechend alten Systemen immernoch gibt. Aktuell sollte man bei der Formulierung von SQL Statements durchaus unbefangen vorgehen, zumindest bevor man Annahmen trifft, die nicht (mehr) stimmen.
Ausnahme wäre, man arbeitet gezielt an einem alten Oracle 7 oder 8. Dann besser die 20(oder 15?) Regeln des RBO durchlesen und befolgen. Bei anderen Systemen entsprechend.

Am Ende bleiben dann vielleicht ein paar Prozent problematischer Abfragenfälle, die etwas Forschung benötigen, einen gezielten Optimzer Hint oder vielleicht sogar eine Denormalisierung des DM.

Prinzipiell beschreibst Du das Vorgehen, wie ich es auch immer gehandhabt habe.
Probleme werden erst (und nur dann) gelöst, wenn sie auftreten. Ein voraussschauende Optimierung, mit Behebung von Problemen, deren Existenz nicht bewiesen ist, erfolgt selbstverständlich nicht.

[Dejan Vu]

Könnte wirklich sein, das das olle Kamellen sind.
Meine Probleme mit den DB sind auch ca. 10 Jahre alt. Mittlerweile überlasse ich das unseren DB-Spezialisten.

[frankyboy1974]

Hallo,

ich möchte hier mal George Orwell (bzw. Benjamin aus Farm der Tiere) zitieren: "Gott habe ihm zwar einen Schwanz geschenkt,
um damit die Fliegen zu verscheuchen,
doch er persönlich würde lieber sowohl auf Schwanz wie Fliegen verzichtet haben."

mfg