(Sybase) Datenbankexperte gesucht

[Ricky Spanish]

Vielleicht gibt's ja hier jemanden, der ein bisschen mehr Ahnung von Datenbanken hat als ich und mir weiterhelfen würde. Problem ist folgendes:

Ich schreibe ein Programm um Daten aus einer Tabelle einer Sybase-Datenbank auszulesen und anzuzeigen. Die Tabelle besitzt zahlreiche Spalten Column1 bis ColumnN.
In einer GUI kann der User nun Filterkriterien festlegen und dann die Datenbankabfrage starten. Nur solche Zeilen, die den Filterkriterien entsprechen, werden angezeigt.

Die Spalten enthalten alle Textstrings (varchar bzw. char). Die Filterkriterien hierfür kann der User aus verschiedenen Listen auswählen und miteinander verknüpfen, z.B.:

SELECT * FROM myTable WHERE (Col1 = 'bla' OR Col1 = 'blub' OR Col1 = ...) AND (Col2 = 'asdf' OR Col2 = 'wsad' OR ...) AND (Col3 = ...

Ich glaube, das Prinzip ist klar.

Nun zu meinem Problem: Das resultierende SELECT-Statement besteht aus einer ziemlich großen Anzahl an ORs und ANDs. Die Datenbank unterstützt leider nur knapp 255 dieser Tokens pro Selection-Level, d.h. ich muss das Statement irgendwie in mehrere Statements aufsplitten.

Hab mir hierzu schon ein paar Gedanken gemacht, aber bisher noch nix brauchbares gefunden.

Die Billig-Methode wäre natürlich, einfach mehrere SELECT-Statements hintereinander abzufeuern und dann die zurückgelieferten Daten in meiner Applikation auszusortieren bzw. zu mergen. Aber das will ich eigentlich nicht tun, weil erstens die Performance darunter leidet und das zweitens imho Aufgabe der Datenbank ist.

Also: Hat jemand ne Idee, wie ich so eine Abfrage realisieren kann, sprich wie ich das obige SELECT-Statement möglichst geschickt in kleinere Statements zerlegen kann, die ich dann mit einer einzigen SQL-Abfrage abfeuern kann? Nochmal zur Erinnerung: Ich brauche das ganze für ne Sybase, d.h. Datenbankspezifische Befehle für z.B. ne Oracle bringen mich nicht weiter.

Danke schonmal im Voraus.

Gruß
M

 

[aMrio]

erstmal rein zum verständnis: du entwirfst ein programm in welchem benutzer über 255 verschiedene filter setzen können / sollen? unwirtschaftlich ist hier mit sicherheit weniger ein 2. select sondern die logik an sich; zumindest erschließt sich mir das nicht.

ansonsten stichwort "diagnostic size"

 

[Ricky Spanish]

erstmal rein zum verständnis: du entwirfst ein programm in welchem benutzer über 255 verschiedene filter setzen können / sollen?

Ich hab's stark vereinfacht erklärt. Ganz so simpel ist das Programm natürlich nicht, aber das würde jetzt zu weit führen.
Vereinfacht gesehen führt es auf das o.g. Problem hin.

ansonsten stichwort "diagnostic size"

Sorry, sagt mir jetzt gar nix. Könntest Du das genauer ausführen plz?

 

[parats']

Wenn ich dich richtig verstehe, dann möchtest Du aufgrund der Beschränkung mehrere Selects zu einem zusammenfassen.
-> Union Select sollte da deine Wahl sein. Hoffe sowas gibt es unter Sybase.

SELECT * FROM Table1
UNION
SELECT * FROM Table2

Ansonsten aber #2 an Amrio.

€: http://www.aspheute.com/artikel/20011015.htm

 

[ViperDK]

Hm wie waers mit subselect nutzen oder ner temp table?

SELECT * FROM myTable WHERE
[ID] IN (SELECT [ID] FROM myTable WHERE (Col1 = 'bla' OR Col1 = 'blub' OR Col1 = ...) AND (Col2 = 'asdf' OR Col2 = 'wsad' OR ...)) AND
[ID] IN (SELECT [ID] FROM myTable WHERE Col3 = ... )

so wuerde ichs jedenfalls instinktiv im ms sql server probieren wenn ich das problem da haette

 

[aMrio]

na er hat doch gar nicht mehrere tabellen sondern eine einzige unglaublich große; wie sie eigentlich nur in ner olap umgebung benutzt wird; wo man aber eigentlich dennoch nicht sone abfragen hat wie hier beschrieben. ein union wird ihm genausowenig nützen wie ein subselect, er will ja nur möglichst weit einschränken und muß keine hierarchien abbilden oder daten abgleichen oder sonstwas.

mein hinweis zielte darauf ab, dass man bei vielen dbms den transaktionen generell einschränkungen geben kann, wie eben die anzahl der möglichen bedingungen. ich kenn nun sybase gar nicht, aber ich kann mir gut vorstellen dass es das da auch gibt. wobei dann wieder fraglich wäre ob 255 nicht der maximalwert ist bereits.

eventuell, ich kenn ja weder tabelle noch was damit gemacht werden soll, kann man mit cases arbeiten, die haben afaik keine mengenbegrenzung. aber ob das sinnvoll ist in bezug auf das zu lösende problem weiß ich halt nicht. möglich wäre vielleicht auch ne view zu nutzen, oder mehrere. dann erspart man sich das sammeln und spätere sortieren in der anwendung. aber auch um das zu beurteilen reichen die infos hier bei weitem nicht aus.

nur wie gesagt, ich denke generell sind sowohl die tabelle als auch die anwendung sehr unelegant durchdacht.

edit: die eckigen klammern da oben tun mir in den augen weh beim lesen

 

[ViperDK]

lies das statement nochmal amrio, ich selektiere nur aus einer tabelle....

go try it.... ist halt interessant das zu zerlegen... wenns lauter ands oder ors sind waere es ne einfache sache, wenns gemischt ist dann wirds lustiger

 

[aMrio]

wo hab ich was anderes gesagt? das mit den mehreren tabellen war auf das union bezogen. wie ihm aber ein subselect helfen sollte wüsste ich nicht, ist ja nicht so dass er dann weniger bedingungen in einer aktion hätte und nicht wieder (vermutlich) über dieses problem stolpern würde. ich seh auch nicht so ganz den sinn in so vielen subselects mit sich selbst.

 

[Whcttyh]

mit union (bzw. intersect) geht das natürlich schon.

 

[ViperDK]

>> Die Datenbank unterstützt leider nur knapp 255 dieser Tokens pro Selection-Level, d.h. ich muss das Statement irgendwie in mehrere Statements aufsplitten.

ich gehe jetzt mal hemmungslos davon aus ein subselect ist ein eigener selection level

 

[parats']

Subselect ist natürlich auch eine Möglichkeit.
Jedoch sind die teils ziemlich inperfomant, müsste man eben mal als query durchlaufen lassen und gucken.

 

[aMrio]

wenn das mit dem selection leveln stimmt, dass das als weiteres zählt und die eingrenzung wirklich auf selection-level ebene ist (ich denke halt die ist je transaktion), dann hast du recht, bedingt. ich verstehe in deinem beispiel das mit dem ID - feld nicht ~

ich würde das dann in dem fall so lösen:

select * from mytable
where col1 in
                                (select col1 
                                 from mytable
                                 where col1 in ('bla', 'blub', 'blob')
and col2 in
                                (select col2 
                                 from mytable
                                 where col2 in ('asdf', 'yxcv', 'qwer');

aber wie gesagt, performant wäre eventuell auch ein gutes viewdesign, oder diverses anderes, dafür kennen wir aber die problemstellung nicht gut genug.

 

[TheScorpion]

aMrio, wieso noch extra nen Subquery?

Select * from mytable
where col1 in ('bla', 'blub', ...)
and col2 in ('asd', 'sdf', ...)

tuts doch auch.
Allerdings wäre noch anzumerken, dass bei "col in (y,x,z)" ein eventuell existierender Index nicht getroffen wird, bei "col=y or col=x" allerdings schon. Bei Sybase speziell kenne ich mich aber nicht aus, eher bei Oracle.

 

[aMrio]

es geht ja gerade darum das er auf dem - eventuell - höchsten "selection level" nur maximal 255 vergleiche anstellen darf. mh ok ich merk grad mein beispiel war wohl echt doppelt gemoppelt, die vergleichswerte werden ja dennoch nach oben weitergegeben und dann hat er wieder die 255 grenze vermutlich? (leider meldet er sich ja nicht mehr)

wie meinst du das mit dem index nicht getroffen? warum sollte das nicht geschehen?

 

[TheScorpion]

Ich weiß nicht, wie bei SyBase ermittelt wird, ob und welcher Index auf eine Tabelle verwendet wird.
Normalerweise ist das so:
bei a = 'x' und Index auf a wird der auch verwendet
bei a like 'x%' und index auf a wird der nicht verwendet, weil "like" nicht indiziert werden kann
bei "a in (a,b,c)" ist das so eine Sache. Es gibt Oracle-Versionen, die einen Index auf a erkennen und verwenden, andere nicht.

Wenn er also bei der alten Variante mit "and" und "or" einen Index trifft, wollte ich nur zu bedenken geben, dass dies bei "IN" nicht so sein muss und er dann nen Full-table-scan hat. Das hängt aber auch noch von eventuellen rules und DB-Einstellungen ab.

 

[parats']

Also unter MS SQL kannst Du auf jeden Fall einen Index mit IN erkennen und verwenden.
Würd mich stark wundern wenn es, Oracle mal ausgenommen, da zwischen den einzelnen DBs so unterschiede gibt.

 

[ViperDK]

Mak muesste halt endlich mal ausprobieren und uns dann Bescheid geben!
Fummeln und optimieren muss er (wenn überhaupt nötig) selbst. Die subselect-loesung kostet vermutlich einen Table-Scan je subselect. Um Indexe würde ich mir jetzt aber mal nicht sooo viele sorgen machen... bei frei definierbaren Suchen ist das eh Glückspiel.

Aber wenn wir schon beim optimieren sind... zieh im Zweifelsfall nen subselect einem UNION vor. Punkt

 

[Ricky Spanish]

Sorry, dass ich mich erst jetzt melde. Hatte die letzten Tage unglaublich viel zu tun.

Aber auf jeden Falll erstmal Danke für die vielen Vorschläge

Ich werde mir das nächste Woche auf der Firma genauer anschauen und dann auf jeden Fall Feedback geben. Vorher komm ich leider aus Zeitgründen nicht dazu.