Abfrage von Werten aus Tabelle

[schwarer]

Habe Beispielhaft eine Tabelle mit folgenden Spalten :
User = Username
Rollen= Zugeordnete Rollen

Und eine Tabelle wo die Rollen als Text hinterlegt sind

Beispiel:

Rolleid: 1
Beschreibung : Admin

Rolleid: 2

Beschreibung: Netzwerkspezialist

usw.

Nun möchte ich User abfragen welche Rollen diese haben , Problem in der Spalte Rolle ist nicht nur ein Wert
eingetragen sondern mehrere Werte mit der dazugehörigen Beschreibung

Beispiel:
User : Paul
Rollen: 1;2;4;6
Beschreibung

User: Rolle: Beschreibung:
--------------------------------------------------
Paul 1 Admin
Paul 2 Netzwerkspezialist
Paul ......
..........

Gibt es da einen einfachen Weg diese Rollen in einer Art Baumstruktur abzufragen per SQL?
Danke im Voraus

 

[akretschmer]

Gibt es da einen einfachen Weg diese Rollen in einer Art Baumstruktur abzufragen per SQL?

Ja. Nennt sich Normalisierung. Du machst einen Fehler, wenn Du Kommagetrennt (oder wie auch immer) mehrere Dinge in einem Feld aufzählst.

Man bekommt das hin, ich könnte es Dir in PostgreSQL zeigen, was ähnlich zu Oraggle ist. Aber ich will nicht Deine Fehler damit zementieren.

 

[akretschmer]

Ja. Nennt sich Normalisierung. Du machst einen Fehler, wenn Du Kommagetrennt (oder wie auch immer) mehrere Dinge in einem Feld aufzählst.

Man bekommt das hin, ich könnte es Dir in PostgreSQL zeigen, was ähnlich zu Oraggle ist. Aber ich will nicht Deine Fehler damit zementieren.

Na gut, ich will mal nicht so sein ;-)

test=*# select * from ding;
 id | eigenschaft
----+-------------
  1 | 1,3,4,6
  2 | 2,3,4
(2 rows)

Time: 0,149 ms
test=*# select * from eigenschaft ;
 id |  t
----+-----------
  1 | blau
  2 | kalt
  3 | hell
  4 | doof
  5 | passend
  6 | unbekannt
(6 rows)

Time: 0,122 ms
test=*# select * from (select *, regexp_split_to_table(eigenschaft,',')::int as e from ding) foo left join eigenschaft on foo.e=eigenschaft.id;
 id | eigenschaft | e | id |  t
----+-------------+---+----+-----------
  1 | 1,3,4,6  | 1 |  1 | blau
  1 | 1,3,4,6  | 3 |  3 | hell
  1 | 1,3,4,6  | 4 |  4 | doof
  1 | 1,3,4,6  | 6 |  6 | unbekannt
  2 | 2,3,4  | 2 |  2 | kalt
  2 | 2,3,4  | 3 |  3 | hell
  2 | 2,3,4  | 4 |  4 | doof
(7 rows)

Wie schon gesagt: das ist nicht schön. Kinder: macht das nicht zu Hause!

 

[akretschmer]

Wie schon gesagt: das ist nicht schön

Schön wäre sowas:

test=*# create table ding (id int primary key);
CREATE TABLE
Time: 38,417 ms
test=*# create table eigenschaft (id int primary key, t text);
CREATE TABLE
Time: 8,915 ms
test=*# create table ding_eigenschaft(ding_id int references ding, eigenschaft_id int references eigenschaft);
CREATE TABLE
Time: 18,999 ms

Damit kannst Du dann auch so coole Dinge wie referentielle Integrität oder Indexe nutzen und nicht so krude Konstrukte wie
regexp_split_to_table()und rumgeCASTe.

 

[schwarer]

Ja. Nennt sich Normalisierung. Du machst einen Fehler, wenn Du Kommagetrennt (oder wie auch immer) mehrere Dinge in einem Feld aufzählst.

Man bekommt das hin, ich könnte es Dir in PostgreSQL zeigen, was ähnlich zu Oraggle ist. Aber ich will nicht Deine Fehler damit zementieren.

Danke aber ist eine Datenbank in der Firma, warum man das so gemacht hat - keine Ahnung

 

[akretschmer]

Danke aber ist eine Datenbank in der Firma, warum man das so gemacht hat - keine Ahnung

Naja. Das ist kein Grund, es mal umzustellen und richtig zu machen, oder? Es fällt Euch auf die Füße, früher oder später. Eigentlich ja jetzt schon, weil Du es nicht gescheit abfragen kannst.

 

[Hony%]

Danke aber ist eine Datenbank in der Firma, warum man das so gemacht hat - keine Ahnung

Keine Ahnung – das dürfte auch die Antwort auf das Warum sein. Die Regeln zur Normalisierung gibt es nicht ohne Grund. Und sie wurden auch nicht als Erkennungszeichen eines elitären Clubs entworfen, sondern um Probleme, wie deine, von Anfang an zu verhindern.

Natürlich lässt sich das eine Problemchen jetzt irgendwie lösen. Aber geht das dann auch noch mit der nächsten Anforderung – oder der übernächsten? Ein Redesign kostet jetzt Zeit, und damit Geld. Allerdings könnte damit in Zukunft wohl auch ein vielfaches der Zeit einspart werden.

 

[akretschmer]

Ein Redesign kostet jetzt Zeit, und damit Geld. Allerdings könnte damit in Zukunft wohl auch ein vielfaches der Zeit einspart werden.

und damit - in der Zukunft - richtig viel Geld. Sorry, aber das muß gesagt werden.