Spalte einer Ergebnismenge soll neue View/Tabelle definieren. Geht das mit SQL?

Liebe Forumgemeinde,

ich habe hier ein kleines Problem und bin mir nicht ganz sicher, ob ich das mit einfacher SQL-Funktionalität erschlagen kann. Deshalb frage ich lieber vorher nach.

Durch eine relativ komplexe Anfrage bekomme ich ein Result-Set aus der Datenbank. Die Struktur könnte folgendermaßen aussehen:

--| -- name: -------------------| -- value ----------------------
01| Vorname                            | Hans
02| Name                                | Müller
03| Geburtsort                         | München
04| Alter                                 | 43
05| Vorname                            | Petra
06| Name                                | Schäfer
07| Geburtsort                         | Berlin
08| Alter                                 | 24

Wie unschwer zu erkennen ist, lege ich hier Personendaten an. Aus verschiedenen Gründen können wir keine konkrete Tabelle t_person anlegen und müssen deshalb zusammengesetzte Typen selber organisieren.

Aus diesem Ergebnis möchte ich gerne ein View o.ä. erstellen, das folgende Struktur hat:

--| -- Vorname: ---| -- Name: ----| -- Geburtsort:----| -- Alter:---
01| Hans               | Müller           | München             | 43
02| Petra              | Schäfer         | Berlin                  | 24

Es soll also eine bestimmte Spalte der ersten Ergebnismenge die Struktur der View bestimmen. Eine andere Spalte der ersten Ergebnismenge soll die Werte enthalten.

Kann mir vielleicht jemand sagen, wie ich so etwas am elegantesten - am besten mit Standard SQL - lösen kann?

Vielen Dank vorab,
–Heiko

Im /contrib findest Du ein Modul ‘tablefunction’ oder so ähnlich, welches eine Crosstab-Funktion mitbringt. Diese tut das, was Du suchst.

Andreas

dürfte das recht schnell zu komplett kapotten Daten führen. Du hast, so wie oben geschildert, keinerlei Bezug zwischen den Zeilen. Hier wäre auch möglich, daß Hans Schäfer 24 ist und in München geboren wurde. Unabhängig von meinem anderen Rat zur crosstab-Funktion würde ich dringend empfehlen, das insgesamt so wie es ist in die Tonne zu treten.

Andreas

Hallo Andreas,

wir sind mit der Lösung auch alles andere als zufrieden. Aber wir stehen vor dem Problem quasi beliebige Kompositionen von Daten abspeichern zu müssen. Dem Benutzer soll hinterher vollkommen frei gestellt sein, wie seine Datentypen (also z.B. Person oder Anschrift) aufgebaut sind. Auch soll es möglich sein, neue Datentypen zu definieren, ohne an der Datenbank zu schrauben.

Ein anderer Ansatz war, für jeden Custom-Datensatz eine eigene Tabellen anzulegen. Das bringt viele weitere Vorteile, wie z.B. Typprüfung. Bei der aktuellen Idee können wir nur varchar ablegen. Allerdings müssen wir dann den Standard-SQL Zweig verlassen was wir überhaupt nicht möchten.

Hast Du noch eine andere Idee, wie man verschiedene Typen sinnvoll anlegen und verwalten kann? In- und Out- Funktionen für TYPE - zu schreiben fällt leider auch aus…

Danke und viele Grüße,
–Heiko

Okay,

ich gebe zu aus dem letzten Posting kann man nichts verstehen. Also noch ein Versuch:

Unsere Applikation soll Metadaten speichern. Wie diese jedoch aussehen, kann im Moment noch niemand wissen. Also brauchen wir eine Möglichkeitm das Ganze dynamisch zu gestalten. Ein Admin der Software muss später natürlich die konkreten Datensätze bestimmen, also festlegen, dass zu einer Person ein Vorname, Name und Geburtsort gehört.
Bei einer anderen Installation wird das aber anders gesehen und der Admin dort ist der Meinung, dass zusätzlich noch das Alter dazu gehört.

Wenn wir zu jedem ‘Custom-Datentyp’ eine eigene Tabelle anlegen würden, müssten wir mit den Tabellen pg_catalog etc. arbeiten. Das hat den bereits beschriebenen Nachteil, dass wir etwas konkretes für PostgreSQL implementieren müssen, was absolut ungünstig wäre.

Aus diesem Grund halten wir uns eine Tabelle, die den Aufbau der Metadaten beschreibt und eine weitere Tabelle, die die konkreten Daten eines Metadatums hält. Aus diesen Tabellen hohlen wir uns später dann die konkreten Werte inkl. Spaltennamen.

crosstab könnte evtl. schon die Lösung für uns sein, da ich in meinem ersten Posting nicht alle Spalten angegeben habe. Durch eine nicht mit abgebildete ID besteht schon die Möglichkeit die Daten eineindeutig zu referenzieren.

Für weitere Vorschläge bin ich jedoch jederzeit sehr dankbar.

Vielen Dank und viele Grüße,
–Heiko

Ja. Gebe Deinen Nutzern einen Kasten mit leeren Karteikarten, die sie dann bemalen können. Gut, damit kann man dann zwar nicht rechnen, aber mit Deinem Modell geht das ja auch nicht.


Sorry, mehr fällt mir da nicht ein… vielleicht, wenn man das Ganze besser kennen würde. Dann normalisiert man das und es sollte gehen.


Andreas

Also ich gebe hier akretschmer Recht: ihr lauft schnurgerade auf einen Haufen Probleme zu, die sich so eigentlich gar nicht lösen lassen.

Die geforderte Flexibilität kann ich verstehen, aber ganz frei würde ich das nicht gestalten sondern auf einigen existierenden Grundlagen aufbauen.

Dann sollte er in der Lage sein, anhand der PK der ‘Haupttabelle’ neue Eigenschaften pro Datensatz zu definieren, incl. Dingen wie ein VIEW, der das dann darstellt. Beispiel:

person ist hier die Hauttabelle, person_mydetail1 die vom Admin 1, der noch das Geburtsdatum dazuhaben will.

test=# create table person (id serial primary key, vname text);
NOTICE:  CREATE TABLE will create implicit sequence "person_id_seq" for serial column "person.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "person_pkey" for table "person"
CREATE TABLE
test=*# create table person_mydetail1 (id int references person, geb_datum date);
CREATE TABLE
test=*# create view my_person_view as select id, vname, geb_datum from person left join person_mydetail1 using (id);
CREATE VIEW
test=*# insert into person(vname) values ('katharina');
INSERT 0 1
test=*# insert into person(vname) values ('tamara');
INSERT 0 1
test=*# insert into person_mydetail1 values (2, '2007-07-28'::date);
INSERT 0 1
test=*# select * from my_person_view;
 id |   vname   | geb_datum
----+-----------+------------
  1 | katharina |
  2 | tamara    | 2007-07-28
(2 rows)

Andreas

Hallo Andreas,

leider spreche ich nicht von einem Datenbankadministrator :-).
Das würde uns alles viel einfacher machen.

Leider müssen wir das über unsere Software lösen…

Vielen Dank für Deine Mühe,
–Heiko