In der Datei Anrede ein Land 0 Anlegen = Standard Texte für
alle Länder
Und dann nur die Datensätze anlegen die von diesem Standard
abweichen.
Der View bekommt dann übergeben:
Suche den Anrede_Text für die Land_ID 99 mit der Anrede_ID 88
Der View Sollte dann in der Physikalischen Datei Nachsehen
gibt es einen Datensatz
mit Land_ID 99 mit der Anrede_ID 88 wenn keiner gefunden wurde
soll er den Anrede_Text von
Land_ID 0 mit der Anrede_ID 88 suchen
Geht das ? (PL-SQL Funktion ) Ist das ein gangbarer Weg ? Wie
geht das im Detail ?
Das Statement, das Du dafür ausführen müßtest ist folgendes:
SELECT a.anrede\_text
FROM personen p, anrede a
WHERE p.land\_id=a.land\_id AND p.anrede\_id=a.anrede\_id
UNION
SELECT anrede\_text
FROM personen p, anrede a
WHERE a.land\_id=0 AND
p.anrede\_id=a.anrede\_id AND
NOT EXISTS (SELECT land\_id
FROM anrede a2
WHERE a2.land\_id=p.land\_id);
Keine Ahnung, ob das ‚not exists‘ SQL Standard ist, auf Oracle funktionierts auf alle Fälle.
Eine kleine Anmerkung dazu: Das so zu machen ist ein durchaus gangbarer Weg, geht aber natürlich auf Kosten der Performance, weil ja ein einfacher SELECT (idealerweise über den primary key in ‚anrede‘) durch zwei SELECTS, davon einer sogar noch mit sub-select ersetzt wird. Sollte aber keine Tragödie sein, so lange Deine Anreden-Tabelle nicht wirklich groß wird.
Hi,
Gegenvorschlag zu TheBeast. Seine Lösung mag funktionieren, nur, wie er schon sagt, ist sie eine ziemliche Performancefalle (Union und Subselect in einer Abfrage).
Zusätzlich werden die Daten vergewaltigt -> nicht den Datensatz, den man findet, sondern einen anderen, wenn man den nicht findet, aber nur dann, sonst doch den - uff!).
Warum legst Du die Daten nicht so ab, wie Du sie brauchst?
Der Anrede_Text ist 90 % der Länder gleich
Ist doch völlig wurscht - für jedes Land gibt es einen, fertig.
Ich will nicht 100 mal alle Anrede_Text (in der Datei Anrede)
anlegen.
Das ist der entscheidende Punkt: warum nicht? 100 Anredendatensätze sind doch nichts, wenn sie Dir einen performancemäßigen Zugang zu deinen Daten bringen. Vergleiche Nutzen und Aufwand beider Methoden!
Das mit den Anrede Titeln und Ländern ist nur ein Beispiel.
zum Hintergrund:
Eigendlich habe ich Mandanten (Firmen) ca 200.
und 15-20 von diesen Nachschlagetabellen und in jeder dieser Tabelle stehen 1 bis 50 Datensätze !
Das gibt schon einen Haufen doppelte Datensätze.
Es gibt ein Programm das auf diese Oracle DB zugreift.
Dieses Programm hat ca. 25 mannjahre Entwicklungszeit und zigtausend SQLs die ich nicht alle ändern will.
In der Datei Anrede ein Land 0 Anlegen = Standard Texte für
alle Länder
Und dann nur die Datensätze anlegen die von diesem Standard
abweichen.
jein. Du hast in Deiner Länder-Tabelle eine Referenz auf die Anreden-Tabelle in Form einer n:1-Beziehung: n Länder „teilen sich“ 1 Anrede. Es gibt keinen Default-Text, sondern einfach nur einen Datensatz (oder ein paar), der häufiger benutzt wird als die anderen.
Damit keine SQLs zu ändern sind:
Hm. Eigentlich überlegt man sich das DB-Layout, bevor man es mit SQL-Statements versieht…
SELECT person.name, anrede.anrede
FROM person, land, anrede
WHERE person.ref_land = land.id
AND land.ref_anrede = anrede.id
Einfach, sauber und hygienisch
Cheatah
P.S.: Evtl. Outer Joins günstig wählen, und natürlich brauchbare Indizes (bei land und anrede auf den Primary Key ‚id‘) erstellen!
[…]und natürlich
brauchbare Indizes (bei land und anrede auf den Primary Key
‚id‘) erstellen!
Bei derart winzigen Datenmengen wie 100 Länderchen oder 'ner Handvoll Anreden kann es u.U. (besonders bei häufig befragten Tabellen) sinnvoll sein, nicht den Umweg über einen Index zu gehen, sondern auf den Cache zu vertrauen. Das ist im Einzelfall in SQL*Plus mittels AUTOTRACE STATISTICS zu testen - wäge Consistent Gets und Physical Reads mit und ohne Indizes gegeneinander ab. Wenn es mit Index besser ist, überlege Dir, ob es nicht sinnvoll ist, z.B. in anrede neben id auch die Anrede selbst mit aufzunehmen - dann holt Oracle sich die Information direkt aus dem Index, anstatt noch die Tabelle zu bemühen.
als allgemeinen Rat… nach ausgiebiger Erfahrung damit, den kostenbasierten Optimizer dazu (nicht) zu bringen, meine Statements so abzufahren, wie _ich_ es möchte, sehe ich bereits die Möglichkeit, etwas anderes als „Rule based“ einzustellen, als Schnapsidee an
oder meinst du nur,
dass sich bei dieser daten"menge" der kostenbasierte nicht
lohnt?
Naja, bei der Planerstellung wird vermutlich die Hälfte der Gesamtzeit draufgehen; aber das passiert ja (sofern Du Bindvariablen verwendest) nur ein mal. Der Grund sind einfach die - meiner Erfahrung nach - miserablen Ergebnisse.
als allgemeinen Rat… nach ausgiebiger Erfahrung damit, den
kostenbasierten Optimizer dazu (nicht) zu bringen, meine
Statements so abzufahren, wie _ich_ es möchte, sehe ich
bereits die Möglichkeit, etwas anderes als „Rule based“
einzustellen, als Schnapsidee an
naja, mir ist egal, ob oracle unsere anwendung so ausfuehrt, wie ich es will, oder anders, hauptsache korrekt und ein bisschen pronto bitte
das meiste habe ich sowieso nicht geschrieben…
Naja, bei der Planerstellung wird vermutlich die Hälfte der
Gesamtzeit draufgehen; aber das passiert ja (sofern Du
Bindvariablen verwendest) nur ein mal. Der Grund sind einfach
die - meiner Erfahrung nach - miserablen Ergebnisse.
wie gesagt, bei uns war es genau umgekehrt: mit rule-based optimizer (vorgabe des anwendungsherstellers) brauchte ein bestimmter report so um die 100 sec, mit cost-based optimizer und aktuellen statistiken etwas ueber eine sekunde. ich haette unsere dba umarmen koennen!
ja, und dazu muss man vernünftig optimieren können Der cost-based optimizer ist dabei meiner Erfahrung nach eher hinderlich.
wie gesagt, bei uns war es genau umgekehrt: mit rule-based
optimizer (vorgabe des anwendungsherstellers) brauchte ein
bestimmter report so um die 100 sec, mit cost-based optimizer
und aktuellen statistiken etwas ueber eine sekunde.
Mit vernünftiger Optimierung und rule-based wird’s dann „unmessbar kurz“[tm]
Klar, wenn man sich selbst nicht um die Optimierung kümmern kann oder will, ist cost-based schon von Vorteil. Dummerweise kann die Datenbank trotz allem nicht denken. Wenn ein Experte sich das Statement richtig zusammenschachtelt und vernünftige Hints vergibt - von den richtigen Indizes ganz zu schweigen - kann Oracle aber keine Spur dagegenanstinken. Oracle ist eben kein Miracle, Human Intelligence aber schon
ja, und dazu muss man vernünftig optimieren können Der
cost-based optimizer ist dabei meiner Erfahrung nach eher
hinderlich.
wie schon gesagt, alte fremde applikation, hunderte tabellen und ca. 100 procedures, meist laenglich =
keine lust das von hand zu optimieren!
Klar, wenn man sich selbst nicht um die Optimierung kümmern
kann oder will, ist cost-based schon von Vorteil.
siehe oben.
Dummerweise
kann die Datenbank trotz allem nicht denken. Wenn ein Experte
sich das Statement richtig zusammenschachtelt und vernünftige
Hints vergibt - von den richtigen Indizes ganz zu schweigen -
kann Oracle aber keine Spur dagegenanstinken. Oracle ist eben
kein Miracle, Human Intelligence aber schon
nun, wenn es trotzdem noch probleme gibt, kann man da immer noch hints geben (werden auch bei cost based beruecksichtigt, scheint mir). an den statements selber drehe ich nach moeglichkeit lieber nicht rum, sonst ist das letzte bisschen support auch noch floeten. das hoechste der gefuehle sind recht konkrete „verbesserungsvorschlaege“ an den hersteller zum absegnen…
Der cost-based optimizer ist dabei meiner Erfahrung nach eher hinderlich.