DBLookupComboBox ohne Lookup-Tabelle

[wolfis]

Hallo wf,

wenn ich die DBComboBox mit der Datenbank verbinde, schreibt er immer die ganze Zeile von Items in die Datenbank.
Ich brauche aber eine Methode, damit nur der index (1-6) in die Datenbank geschrieben wird

[Sir Rufo]

Ein TClientDataSet nehmen und an die LookupComboBox hängen

[Furtbichler]

Es ist keine Schande (im Gegenteil) Lookuptabellen mit nur sehr wenigen Einträgen in der DB zu haben. Deine Spalte hat z.B. die Werte 1,2,3,4,5,6. Dies repräsentiert Farben (rot,blau,grün,gelb,grau,schwarz).

Ohne eine derartige Lookuptabelle (und natürlich einem FK-Constraint) weiß keine Sau, was 1,2,3,4,5,6 bedeutet. Mit Lookuptabelle schon. Deine Daten sind somit nicht nur dokumentiert, es ist mit einer Lookuptabelle auch möglich einen vollständigen Report zu generieren, ohne deine Anwendung zu verwenden.

Eine Lookuptabelle *nicht* zu verwenden, ist ein Anti-Pattern.

[jobo]

Furtbichler hat meine vollste Zustimmung!
Allein die Zeit, die Du bis jetzt vergeudet hast, eine none-standard Lösung zu finden, ist schon rausgeworfenes Geld.
Ganz zu schweigen von den Effekten, die sich dann irgendwann ergeben.
Z.b. an dem Tag, wo jemand rausfindet, dass man da viel mehr Werte eintragen kann, als Deine Anwendung erlaubt, geht der Ärger los. Vielleicht ist grad niemand da, der Deine Anwendung umprogrammieren kann, es ist aber dringend. Oder oder oder, das Leben ist kreativer als ich..

Diese ganzen Sparideen ergeben meist nur eins, ein Codemoloch im Client.

Und was war noch mal der Overkill? Ein vier Zeilen langes Create Table für die Lookupwerte?
Overkill (für den Anwender) würde ich sagen beginnt bei > 50 Einträgen im Lookup.
Darunter ist alles bestens, darüber sollte es eher eine filterbare LookupCombobox sein.

[Union]

Von DevExpress gibt es dafür die TcxDBExtLookupComboBox. Das Ding hat ein EditValue, das beliebig belegt werden kann und an das Popup kann ein Grid-Repository gehängt werden. Ich verwende das z.b. bei Selektionen, wo ich intern eine ID brauche, die aber nur im Erfassungdsdialog existiert. So spart man sich das Generieren eine extra Datasets.

[Furtbichler]

Ich habe früher ein TdxMemData dafür verwendet (also ein In-Memory Dataset, so wie das himitsu und Sir Rufo bereits erwähnt haben. Ich wollte hier nur eindringlich davor warnen, qualitative Merkmale einer Datenbank außerhalb dieser zu beschreiben, wie dies hier offensichtlich erwünscht und wohl auch von einigen Mitstreitern praktiziert wird.

[Perlsau]

Ich gehe sogar so weit, daß ich in zahlreichen DB-Anwendungen eine Tabelle Geschlecht (3 Einträge: unbekannt, männlich, weiblich) mitführe, die z.B. auch die jeweilige Anrede enthält, manchmal auch eine Titel-Tabelle. Oder für meine Video-Verwaltung eine Tabelle Formate (wenige Einträge) und sogar eine Tabelle Dateisysteme (bislang zwei Einträge: Fat32 und NTFS). Ich verstehe das auch nicht, wieso man sowas unbedingt in der Anwendung unterbringen sollte. Das macht doch den Kohl nicht fett, hier zusätzliche Tabellen anzulegen, erleichtert Programm-Entwickung und -Pflege und Neuentwicklung. In den meisten DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.

[Furtbichler]

Zitat von Perlsau:

In den meisten DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.

Na ja. Die Adresse des DB-Servers in der DB zu speichern ist vielleicht nicht ganz so zielführend.

Aber sonst:

Leider gibt es ein kleines Problem dabei, das gelöst werden muss. Angenommen, wir haben eine Eigenschaft 'Geschmack' mit der entsprechenden Tabelle 'Süß', 'Sauer', 'Bitter', 'Salzig'. (Werte = 1,2,3,4)

Nun muß die Software bie einem süßen Gericht Schlagsahne anbieten. Also muss die Anwendung wissen, das 'Süß=1' ist. Das ist natürlich kein Riesenproblem, aber diese Tastsache ist an zwei Stellen hinterlegt (in der DB und in der Anwendung). Ändert man z.B. die Reihenfolge in der DB (bei einer Neuinstallation z.B.), funktioniert die ganze Anwendung nicht mehr.

Wie gesagt: Ein grundsätzliches Problem, das normalerweise nicht zum Tragen kommt (außer, ein Schwachmat editiert die Lookuptabelle), aber hier würde ich trotzdem noch Prüfungen einbauen und z.B. sicherstellen (per Trigger z.B.) das die Tabelle nicht änderbar ist. Alternativ kann eine solche Tabelle auch ein 'Tag' Element enthalten, das die eigentliche Semantik abbildet. D.h. nicht die ID der Lookuptabelle definiert die Eigenschaft, sondern das Tag-Element. Dieses Element kann nicht verändert werden, aber z.B. der Text, dann ist die Tabelle übersetzbar. Natürlich ist man wieder am Arm, wenn man 'Süß' mit 'Salt' übersetzt...