Output genereller Datenbank-API

[cuanuriaq]

Hallo,

ich bin auf der Suche nach einer geschickten Art und Weise folgendes Problem zu lösen.(Ich habe eine Lösung die mir aber zu kompliziert erscheint)

Der Anwender soll:
1)Datenbank aussuchen und verbinden/löschen/anlegen etc. (check)
2)SQL-Befehle erstellen (select, insert, update, etc) per: (check)

ExecuteDataBaseCmd(const char *pstrCmd)

3)Die Daten im SQL-Statement auslesen und sie weiter benutzen.

ReadNextData(unionData *pstData)

Die obige Methode liest das nächste Tupel aus dem Statement wenn vorhanden.
Nun wird das Resultset Spalte für Spalte durchlaufen. Structtyp, Datentyp, Spaltenname und Daten werden in eine dafür vorgesehene Struct gespeichert und diese kommen dann in das Union-Array *pstData.
Beispiel MySQL Integer:

struct structMySqlInt
{
	unsigned char typeId;
	unsigned short colId;
	unsigned int data;
	char *colName;
};

Mein Unmut liegt nun darin, dass der Anwender für jede Spalte herausfinden muss welche Struct benutzt wurde und jede Struct viel Redundanz hat durch immer wiederkehrende Spaltennamen.

Kennt jemand einen besseren Ansatz die Daten für den Anwender zugänglich zu machen ohne das er in Kontakt mit SQL kommt. ( Ausser die Executecommands?)

mfg cuanu

[Mechanics]

Deine API ist generell nicht schön, wenn das C++ und kein C sein soll. Vor allem das char * colName. Was passiert, wenn man den struct kopiert, wer darf das Ding aufräumen?
Wir haben in der Arbeit teilweise eine eigene Datenbank API und teilweise benutzen wir auch Qt, wobei die von der API her vergleichbar sind. Ich verweis dich mal an Qt, weil man sich das einfach anschauen kann. Da gibts eine QSqlQuery, die führt eine Anfrage aus und kapselt gleichzeitig das Ergebnis (ist bei uns nicht so, wir haben ein ResultSet). Bei der query kannst du dann next aufrufen und ein QSqlRecord bekommen. Von dem kriegst du die Daten einer Zeile als QVariants (oder wenn du kein Qt verwendest, kannst du auch eine ähnliche Variant API bauen, z.B. mit boost::any oder einfach getInt, getString usw.). Und von dem record kriegt man auch Informationen über die Spalte. Ob der Record die Informationen jetzt selber speichert oder intern nur einen Zeiger auf eine ColumnDescription oder was auch immer bekommt, ist eigentlich egal.