SQL: Problem mit Gruppierung

[milamber]

hallo

ich brauche mal einen kleinen Tipp
Folgendes Problem:

Datensatz d1 enthält folgende Werte (String):
"x y 0n f"
"x 0n p"
"y 1m p"
"z 2v y"
"h z 2v y"
usw.

wichtig ist Folgendes: jeder String hat eine Zahl zwischen 0 und 3, die irgendwo enthalten ist. Ich möchte nun nach dieser Zahl gruppieren. Also alle Felder, die irgendwo eine 0 enthalten zusammen, alle die eine 1 enthalten, usw.

Ich bräuchte also sowas wie "extractNumber(d1)" zum filtern um dann gruppieren zu können. Gibt es sowas in SQL? Hat jemand eine Idee?

 

[amarok]

wird soweit ich weiß mit reinem sql nicht möglich sein, mag mich allerdings irren.

 

[patz]

Glaub nicht, dass das irgendwie möglich ist mit normalem SQL.
Das wäre auch endlos langsam. Ich würd das lieber "in Software" selbst implementieren oder die Tabelle anders gestalten.

 

[Trapper]

Die Spalte mit dem relevanten String sei st benannt.
Vorschlag:

SELECT 
   CASE WHEN st LIKE '%0%' THEN 0
           WHEN st LIKE '%1%' THEN 1
           WHEN st LIKE '%2%' THEN 2
           WHEN st LIKE '%3%' THEN 3
   END AS extractedNumber
FROM tabelle
GROUP BY extractedNumber

 

[milamber]

vielen Dank Trapper, ich werde es heute testen

 

[milamber]

hat nicht gefunzt. Access meckert .

ich habe heute auf die Schnelle Folgendes versucht:

mid(st; inStr(st;[0-3]); 1)

aber an diesem "[0-3]" ist es gescheitert. Man kann offensichtlich nicht einen Bereich als Suchkriterium eingeben, ist das richtig so?

 

[Trapper]

hat nicht gefunzt. Access meckert .

Achso, ich dachte, es geht um eine richtige Datenbank. Mit MySQL funktioniert mein vorgeschlagenes Statement beispielsweise problemlos.

 

[crossinger]

Achso, ich dachte, es geht um eine richtige Datenbank.

*räusper* Soooo schlecht ist die SQL-Engine von Access gar nicht. Kann z.B. schon ewig verschachtelte SELECTs (subselects), da hatte mySQL enorm Nachholbedarf.

EDIT: Das Beispiel mit INSTR ist schon deshalb problematisch, da instr() im SQL von Access gar nicht definiert ist (mid() sehr wohl). Und reguläre Ausdrücke sind da schon gar nicht möglich.

EDIT2: Du könntest Einzelabfragen nach Deinem Beispiel (0,1,2,3) durchführen und die Teilergebnisse mittels UNION verknüpfen.

*J*

 

[Trapper]

*räusper* Soooo schlecht ist die SQL-Engine von Access gar nicht.

Mag sein - ich will hier keinen Flamewar starten

Da der OP aber in der Kategorie Web-Programmierung eines Mac-Forums gepostet hat und Access mit keinem Wort erwähnte, ging ich von einem "richtigen" DBMS im Backend-Bereich aus. Und mit derartigen Systemen (etwa Oracle oder auch MySQL ) funktioniert mein Vorschlag

 

[milamber]

meine idee mit inStr geht, allerdings nicht mit einem "Bereich" sondern nur mit einem genau definiertem Suchstring.

das mit UNION habe ich auch schon überlegt.

Das Problem ist aber insgesamt ein wenig komplexer. Es sind einige Tausend Datensätze, von den ich Pivot Charts erstelle. Und wie es sich für MS gehört, ist die Sache nicht ohne Weiteres möglich. Ich will ja nicht über Office schlecht reden, weil es von MS ist, aber hey, je tiefer ich in die Office Programmierung und Automatisierung von Abläufen eintauche, desto mehr graue Haare bekomme ich. Ich bin schon öfters an Grenzen gestoßen, als es mir lieb ist.
Und wisst Ihr was das für mich das größte Geheimnis von MS Software bleiben wird? Diese schlampige Architektur. Ich kann als Informatiker einfacher nicht verstehen, warum es z.Bsp. mehrere verschieden Module für Diagramme gibt, die auch noch alle anders zu bedienen sind. Je nach dem ob man PivotCharts in Access, Access Berichte, Access Formulare, Access Webseite oder Excel erstellt, sind die Möglichkeiten und die Bedienung ganz anders. Einige Dinge, die an einer Stelle gehen, funktionieren wieder an einer anderen nicht und umgekehrt.

 

[milamber]

@Trapper
ja, hab wirklich vergessen zu erwähnen, dass es in Access realisiert wird, aber da die SQL Umsetzung in Access ja relativ in Ordnung ist, dachte ich dass ich das schon irgendwie umgesetzt bekomme.

 

[tjp]

Das Problem ist aber insgesamt ein wenig komplexer. Es sind einige Tausend Datensätze, von den ich Pivot Charts erstelle.

MS will auch MS SQL verkaufen, daher darfst Du Dich nicht wundern, wenn das DBMS Backend von Access limitiert ist. Wenn Du ein richtiges DBMS Backend brauchst, dann kannst Du MS SQL für viel Geld anschaffen (bzw. dein Boss) oder ihr nehmt PostgreSQL oder MySQL. PostgreSQL ist mein Favorit, kann viel, kostet nix, ist frei und wird nur von Oracle oder DB2 übertroffen.

Und wisst Ihr was das für mich das größte Geheimnis von MS Software bleiben wird? Diese schlampige Architektur.

Willkommen im Club

 

[crossinger]

MS will auch MS SQL verkaufen, daher darfst Du Dich nicht wundern, wenn das DBMS Backend von Access limitiert ist. Wenn Du ein richtiges DBMS Backend brauchst, dann kannst Du MS SQL für viel Geld anschaffen (bzw. dein Boss)

Access ist eh' ein Auslaufmodell! Wie wäre es stattdessen mit dem (kostenlosen) MS-SQL Express? Vom SQL-Sprachumfang sollte das mit dem großen Bruder identisch sein! Man könnte es sogar als Backend für ein bestehendes Access verwenden. (Wobei ich die Kombi Access+SQL-Server mit dem 2005er noch nicht getestet habe, sondern nur den etwas sperrigeren Vorgänger SQL2000 am Start hatte).

*J*

 

[milamber]

das mit dem Wunsch nach besserer Software ist ab einer bestimmten Größe der Firma nicht mehr so einfach .

ich habe es übrigens hinbekommen, es war so einfach, dass ich mir an die Stirn klatschen musste. Mir ist irgendwann aufgefallen, dass man eigene VBA Funktionen in SQL verwenden kann. Daran habe ich überhaupt nicht gedacht ... na ja, man lernt immer was dazu .

Dafür habe ich jetzt ein anderes Problem mit PivotCharts .