Design-Frage für riesen DB
-
Hi Leute ich hab grad die Aufgabe bekommen ein kleines Tool zu schreiben, das Daten aus einer DB anzeigt und ein paar kleine Suchfunktionen aufweist. Damit tu ich mir momentan auch gar nicht schwer, mein Problem ist nur wie zeige ich diese Daten an? Das Problem ist es sind momentan 152 Spalten mit ~6350 Einträgen, die täglich steigen. Wie bleibt das ganze am übersichtlichsten?
Tabellenform?
Edit-controlls?
Comboboxen?
Gruppiert und auf Property-Pages?
Und wieviele Datensätze kann ich da dann laden (anzeigen), dass ich noch in ner Vernünftigen Zeit und im angemessenen Arbeitsspeicherbereich bleibe? denn Wenn das Ding dann richtig anläuft kommen da täglich ca. 2000 Datensätze dazu über eine Laufzeit von ca 8 Jahren, ich kann unmöglich immer alles laden.
-
Also ich weiss ja nicht was du da so für Daten hast, aber 152 Spalten hört sich schonmal merkwürdig an, ist das schon dritte Normalform *g*?
Wenn sich die Daten irgendwie logisch zueinander gruppieren lassen wären PropertySheets warscheinlich nicht schlecht. Ne tabelle mit 152 Spalten ist jedenfalls in den meisten Fällen Blödsinn
Du könntest ja immer einen Datensatz über mehrere PropertySheets darstellen, und zur Auswahl ein Suchfenster mit ner CListCtrl mit den wichtigsten Auswahlkriterien.
Damit du bei einer großen Abfrage nicht alles ins ListCtrl schreiben musst gibts es glaub ich sowas wie bulk_row_fetch oder so, damit kann man angeben wieviele Zeilen vom Ergebnis zurückgegeben werden sollen.mfg
tobi
-
Es geht um einen Tester der bei jedem Test sämtliche Daten zu dem geprüften Bauteil speichert. Da dabei sehr viele Sachen getestet werden sind es nun mal einige Spalten. Mit der Gruppierung muss ich mal schauen ob ich die Daten irgendwie gruppieren kann, so dass ich sie aufteilen kann.Mit ListCtrl hab ich zwar noch nichts gemacht aber in diesem Sinne werde ich mir das mal anschauen. Was auf jeden Fall mal ein guter Tip ist, ist bulk_row_fetch, sowas brauch ich unbedingt
-
Du kannst z.b. mit listboxen oder listboxen + listview arbeiten
Links die Bauteile ( alle aufführen )
rechts in der listbox oder listview die daten anzeigen ist dann halt 152 rows langdie daten des bauteils nebeneinander anzeigen ist dumm, zeigs ganznormal untereinander an. entweder in einer listbox oder wenn daten "map" werte haben, kannste auch in 2-3 spalten machen
z.b.
links---------------Box
--------------------1 spalte ---- 2 Spalte
Bauteil-------------Temp---------- C 55
--------------------eigenschaft ---1
-------------------- blawert ----- 5643wenn nur einbauteil brauchst die linke box nicht
wenn viele oder mind. 2 dann wenn er doppelklick macht auf bauteil dann die eigenschaften auflistenwo ist das prob??
-
wo ist das prob??
Das niemand weiß, was die Nutzer brauchen?
Und das wissen wir natürlich auch nicht....
Alternative zu newkid_s Vorschlag: Eine Übersichtstabelle: eine Zeile pro Bauteil, mit enweder aggregierten / den wichtigsten Werten (z.B. name, "geht / geht nicht", ...), sowie ein Detaildialog: alle Werte für ein Bauteil in einer Liste erscheint sinnvoll.evtl: Die Spalten der Übersichtsliste auswählbar machen
evtl: Splitter, links die Übersichtsliste, rechts die Detailliste für das links gerade ausgewählte BauteilJetzt zur Zeilenzahl in der Übersicht:
gut, in 8 Jahren sind wir dann bei 6 Mio Einträgen. Kann man nur hoffen, daß es dann 210" - Monitore gibt, damit der Scrollbar entsprechende bedienbar bleibt...
Im ernst: Die Darstellung "schaffst" du problemlos mit einem virtuellen List Control (LVS_OWNERDRAW, MSDN, codeproject, google, ...). Dabei wirst du für jeden gerade sichtbaren Item nach den Daten gefragt. Du mußt nur wissen, wieviele Einträge es sind, und hälst am besten einen MRU cache (ein paar tausend Einträge), um die Datenbankabfragen gerng zu haltenDu brauchst aber auf jeden Fall einen Zeilen-Filter (z.B. Bestimmtes Datum, Datumsbereich, bestimmte Eigenschaften, ...)
Denn Filter kannst du glücklicherweise auf die Datenbank abschieben.
(Ist ne total geile Aufgabe die du da hast :neidisch sei: )
-
HI zusammen erst mal ein riesen Dankeschön an alle die sich da mit mir gedanken machen / gemacht haben. Ich werde mir die ganzen Vorschläge mal durchschauen und dann nochmal abwägen wo bei was welche Vorteile liegen. Ich habe jetzt mal mit dem Arbeitskollegen der die Maschine programmiert hat gesprochen (der ist auch Schuld an der riesen DB) und jetzt sind mir so die einen oder anderen Spaltennamen wesentlich klarer geworden und ich hab das ganze mal in 5 Kategorien aufgeteilt. Was mich glaub Designtechnisch wesentlich weiter bringt ist meine Gruppe mit wesentlichen Daten das sind nur 9 Spalten, da bleibt das ganze dann wenigstens auch übersichtlich! Die Details dazu anzeigen muss ich mir nochmal eure Vorschläge vornehmen, aber ich denke mit eurer Hilfe bekomm ich das schon hin
P.S.: Kann es sein das VC++ ab 144 Spalten ein Problem bekommt mit dem automatischen erstellen von membern und den Zuweisungen Member - Tabelle? Also quasi wenn ich ein Recordset anlege und dann eine Tabelle wähle die mehr als 144 Spalten hat? Der hat mir alles so durcheinander gebracht und wie gesagt nur 144 durft alles von Hand schreiben. 152 Member anlege 152 Initialisierungen, 152 DDX Zuweisungen
ätzend