Array mit DB Ergebnismenge vergleichen

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1402189)

Ich war davon ausgegangen, dass es mehrere Nutzer mit dem Namen "Bernd" geben könnte, also auch mehrere Datensätze,
aber im Printip geht es dann auch wie bei Uwe Raabe, aber vielleicht noch mit einem DISTINCT usw.

In der konstruierten A-Tabelle gibt es jeden Namen nur einmal. Da der JOIN ja bewusst ins Leere läuft, können wir uns das DISTINCT sparen.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1402189)

@Delphi.Narium: Warum keine Temp-Table? (am Besten nur für diese Session)

Um es auf allen Systemen gleich zu haben und nicht bei der Portierung immer daran zu denken:

Hier hab' ich die Tabelle, dort ist es eine Temp-Tabelle, die ich mir ggfls. anlegen bzw. befüllen muss. Anderswo geht ein Select auch ohne Angabe eines Tabellennamens, ...

'ne Temp-Tabelle für eine Session muss ich dann pro Session entsprechend "versorgen". Pech, wenn ich dann "mal eben" von FireBird nach Oracle wechsel, dann muss ich den entsprechenden Quelltext "weglassen", brauche also ein (wenn auch nur marginal) andere Implementierung. Mag es halt, wenn ein Programm unverändert gegen jede x-beliebige Datenbank läuft. Sorge halt dafür, dass auf Datenbankseite eine möglichst große Übereinstimmung besteht, sodass ich mir im Programm keine Gedanken darüber machen muss, welcher Quelltextbereich, welche SQLs ... nun bei der Nutzung von Datenbank X zu nehmen sind, welche bei Datenbank Y und was muss ich morgen machen, wenn noch Datenbank Z unterstützt werden soll?

Mit der Einheitlichkeit der SQL-Möglichkeiten zwischen den verschiedenen Datenbanken ist es ja nunmal nicht so weit her. (Wie man ja auch hier an den unterschiedlichen Lösungen sehen kann.)

Meine Lösung sieht halt so aus, dass ich für möglichst große Einheitlichkeit auf Datenbankseite sorge. Und da scheint mir das einmalige Anlegen und Befüllen der Tabelle Dual eben ein gangbarer Weg zu sein. (Und ja, es ist nur einer von vielen möglichen.)

[jobo]

Zu dual:
Selbstgestrickt ist okay, aber wer mal ein update oder insert auf der Oracle Dual Tabelle versucht, wird feststellen, dass das nicht geht. Man sollte diesen Effekt mit nachbauen sonst erlebt man eines Tages böse Überraschungen.

dual bei firebird:
RDB$DATABASE (man kann natürlich in jedem System eine Table nehmen, die verspricht nur einen Datensatz auszugeben)

dual bei mssql:
dual einfach nicht angeben

dual bei postgres
wie mssql oder oracle extension installieren

usw.

Temptable: muss man leider immer wieder anlegen

ansonsten:
Es gibt DB, die können auch gleich arrays, records, xml, json, ..? und das per SQL abfragen oder je nach Bedarf vorwärts / rückwärts konvertieren, also StringZuArray, usw.

Performance:
ganze Tabellen aus der DB abzusaugen, um sie mit ein paar lokalen Daten zu vergleichen, das ist vielleicht wie alle Vögel aus Athen holen, um zu schauen, welche davon Eulen sind (oder keine)

P.S: Die Variante von Uwe mit outer Join gefällt mir am besten.

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1402201)

Zu dual:
Selbstgestrickt ist okay, aber wer mal ein update oder insert auf der Oracle Dual Tabelle versucht, wird feststellen, dass das nicht geht. Man sollte diesen Effekt mit nachbauen sonst erlebt man eines Tages böse Überraschungen.

Doch, das geht auch unter Oracle, man muss nur die passenden Rechte haben ;-)
Und ja, das ist eine sehr schlechte Idee, weil sich dann halt die Ergebnisse entsprechend der Anzahl Sätze in Dual "vervielfältigen" oder bei leerer Dual "wegbleiben" ;-)

Wenn man sein eigenes Dual baut, dann muss man sicherstellen, dass da niemand was dran manipulieren kann. Muss man aber letztlich auch bei allen anderen Tabellen, an die der User "nicht dran darf" bzw. nur lesend ...

[himitsu]

Zitat:

Zitat von Delphi.Narium (Beitrag 1402197)

Zitat:

Zitat von himitsu (Beitrag 1402189)

@Delphi.Narium: Warum keine Temp-Table? (am Besten nur für diese Session)

Um es auf allen Systemen gleich zu haben und nicht bei der Portierung immer daran zu denken

Vorallem falls mal wer auf die blöde Idee kommt sowas in einer MultiUserDB zu machen, wo mehrere gleichzeitig auf die "selbe" Tabelle schreiben und ihre Daten gegenseitig löschen und füllen würden. :stupid:


PS: das "Dual" als View ala "SELECT true" oder als StoredProc und schon kann auch ohne Rechtevergabe niemand was dran ändern. :angle:

[mkinzler]

Zitat:

Temptable: muss man leider immer wieder anlegen

Eine globale (GTT) kann man auch als persistent konfigurieren.

[rokli]

Hallo Jungs!

Vielen Dank für die Infos! Im Moment halte ich die Idee von Uwe auch für die Beste - und wahrscheinlich auch die performanteste.

Gruß
Rolf

[jobo]

Zitat:

Zitat von rokli (Beitrag 1402230)

Im Moment halte ich die Idee von Uwe auch für die Beste - und wahrscheinlich auch die performanteste.

Sag ich doch :)

dual oder was auch immer:
Es sollte möglichst nicht nur eine Rechtefrage sein, sondern auch per Constraints abgesichert sein.

Was Einheitlichkeit angeht, bietet sich natürlich ein View an, wie Himitsu sagte. Ob der unbedingt dual heißen muss, sei dahin gestellt. Ich denke, genau wie jeder (jedes Unternehmen) ein set von "home grown" Delphi units hat, hat man eine solche View Schicht vielleicht für die hauseigenen Anwendungen.

Viele solcher Statements oder Scripte kursieren auch im Netz beim Thema Datenbankmigration. Die sind in der Regel darauf gemünzt eine DB sql kompatibel zu einer anderen zu machen, aber das kann man ja auch an eigene Bedürfnisse anpassen.

[Jumpy]

Zitat:

Zitat von jobo (Beitrag 1402232)

Zitat:

Zitat von rokli (Beitrag 1402230)

Im Moment halte ich die Idee von Uwe auch für die Beste - und wahrscheinlich auch die performanteste.

Sag ich doch :)

Gibts sowas auch für Oracle? Das mit der Values(...) kannte ich so noch nicht.
Oder gäbe es da eine andere Möglichkeit das mit Join zu lösen, statt mit Subselect?

[jobo]

Zitat:

Zitat von Jumpy (Beitrag 1402236)

Gibts sowas auch für Oracle? Das mit der Values(...) kannte ich so noch nicht.
Oder gäbe es da eine andere Möglichkeit das mit Join zu lösen, statt mit Subselect?

Es gibt erstmal die Table Function, darüber kann man views, functions, vermutlich auch package functions und letztlich auch Wertelisten einbinden.
Wenn es erstmal dann erstmal Tabelle ist, dann von da an normal mit Join weiter.

Code:

select column_value 
from table(sys.dbms_debug_vc2coll('One', 'Two', 'Three', 'Four'));
..
select column_value 
from table(sys.dbms_debug_vc2coll(1,2,3,4));
..
select distinct column_value from table(sys.odcinumberlist(1,1,2,3,3,4,4,5))

aus SO:
https://stackoverflow.com/questions/...lues-in-oracle

für "Spezial"funktionen z.B.:
http://stevenfeuersteinonplsql.blogs...ction-and.html

P.S.: Bevor man das so wie im Beispiel einbindet (entsprechende Berechtigungen müssen da gesetzt sein), würde ich auch hier empfehlen für die sys functions Wrapper im Anwendungsschema oder Tool Schema zu definieren, die dann mit normalen Berechtigungen auskommen. Dann werden zwar bei der Erzeugung der Wrapper Sonderrechte benötigt, aber die Wrapperfunktion ist dann ein normales Schemaobjekt ohne Sonderlocken.