So allgemeine Fragen nerven hoffentlich nicht zu sehr.

Ich möchte eine erstmal recht einfach aufgebaute Software schreiben. Scheitere bei meinen Überlegungen aber an viel Unwissenheit, so weiß ich, je mehr ich lese, immer weniger wie ich es anstellen soll

Worum geht's?
Eine unbekannte Menge von Datenfeldern soll gelesen und daraus eine Oberfläche aufgebaut werden.
Dabei ist das Prinzip der Daten klar.
Gruppe
Abfrage1
Abfrage2
Abfrage3
Abfrage4
Abfrage5
Abfrage6
Gruppe
AbfrageA
AbfrageB
AbfrageC

usw.

Die Oberfläche soll dann so aussehen
Gruppe
Abfrage1 Abfrage1.txt
Abfrage2 Abfrage2.txt

usw.

Werden Daten in die Textfelder eingetragen, sollen sie gespeichert werden.
Die Daten müssen später wieder aufrufbar sein, auch wenn sich die Grundstruktur der Oberfläche durch eine neue Definition geändert hat.

Ich dachte ich schreibe eine XML Datei und speichere darin die Daten für den Aufbau der Oberfläche.
Ändert sich die XML irgendwann, muss die Software eine andere Oberfläche aufbauen können.
(Hintergrund, der Benutzer soll sich die Abfragen selbst definieren können oder von mir definieren lassen können.)

Ich frage mich an dieser Stelle wie ich die Daten am besten speichere, immer eine neue XML Datei die dann Definition der Oberfläche plus eingegebene Daten enthält?
Ich stelle mir das langsam vor, wenn ich beim öffnen jeden Datensatzes die Oberfläche neu aufbauen muss und das dann auch noch über Interpretation einer XML Datei.

Auch die Suche nach den Daten stelle ich mir langsam vor, wenn ich ewig viele Textdateien durchsuchen muss.
Es soll möglich sein nach bestimmten Kriterien zu suchen, z.B. um alle Datensätze die einen bestimmten Wert haben in einer Liste anzuzeigen usw.. Vielleicht auch die Möglichkeit zusammengehörende Datensätze vergleichend nebeneinander anzuzeigen usw.

Abgesehen von der Grundsätzliche Frage, wie also die Definition einlesen und wie die Daten speichern, frage ich mich auch wie man gewährleisten kann, dass die Anwendung sich leicht zu Windows 8 portieren lässt, ohne das eine Datenbank verwendet wird die dort nicht unterstützt wird oder sowas.

So ein Haufen Wörter, ich hoffe verständlich.
Wäre schön, wenn Ihr mich in die richtige Richtung schupsen könntet, damit ich nicht alles drei oder vier mal programmieren muss

Naja, eine Datenbank wäre schon passend.

Wie das mit dem Portieren auf andere System aussieht, musst du nachlesen.
Aber ich habe in letzter Zeit recht viel von SQLite gelesen, das wird meines Wissens nach auch auf Smartphones verwendet, außerdem gibt es eine ganz gute Doku.


Wenn es nur um Darstellungsoptionen geht (Design zum Beispiel), dann finde ich da eine XML eher angebracht, oder ein anderes Format.
Da musst du dann entscheiden, was im Kontext sinnvoller ist.

Palladin007 hat folgendes geschrieben :

Naja, eine Datenbank wäre schon passend. Wie das mit dem Portieren auf andere System aussieht, musst du nachlesen. Aber ich habe in letzter Zeit recht viel von SQLite gelesen, das wird meines Wissens nach auch auf Smartphones verwendet, außerdem gibt es eine ganz gute Doku. Wenn es nur um Darstellungsoptionen geht (Design zum Beispiel), dann finde ich da eine XML eher angebracht, oder ein anderes Format. Da musst du dann entscheiden, was im Kontext sinnvoller ist.

Ja sqlite habe ich auch gelesen, bin mir nicht ganz sicher ob das auch unter wpf geht, aber ich denke Windows 8 und Windows Phone 8 sollte gehen.

Allerdings fehlt mir schon die Vorstellungskraft um die Daten in eine Datenbank zu speichern.
Ich habe das Denken, dass man eine Tabelle macht, benennt die Spalten und speichert passende Werte in jede Zeile. Aber wenn die Spalten sich ändern, in Anzahl und Bedeutung, wie kann man das dann in eine Datenbank speichern?

Warum sollte das nicht unter WPF klappen?
WPF ist egal, welche Datenschicht du hast, die solltest du sowieso gründlich von der View trennen.

Und wenn sich die Spalten ändern können, dann fang bloß nicht an, die Datenbank zur Laufzeit zu bearbeiten.
Das geht zwar, kann mir aber vorstellen, dass du damit schnell in Teufelsküche kommst.

Viel einfacher ist es, die Namen der Spalten in einer eigenen Tabelle zu halten und dann in einer weiteren Tabelle die Werte der Spalten, dazu die Tabelle mit den Namen referenziert.
Das Prinzip wenden wir auf der Arbeit an mehreren Stellen erfolgreich an, somit hat der Kunde die Möglichkeit, das Daten-Format individuell zu gestalten.

Palladin007 hat folgendes geschrieben :

Viel einfacher ist es, die Namen der Spalten in einer eigenen Tabelle zu halten und dann in einer weiteren Tabelle die Werte der Spalten, dazu die Tabelle mit den Namen referenziert. Das Prinzip wenden wir auf der Arbeit an mehreren Stellen erfolgreich an, somit hat der Kunde die Möglichkeit, das Daten-Format individuell zu gestalten.

Oberflächlich verstehe ich zwar was Du sagst, aber praktisch und wirklich nicht mal im Ansatz
Hast Du dafür irgendwie mehr Informationen oder ein Beispiel damit ich das (hoffentlich) nachvollziehen kann.

Was genau macht eine einfache Datenspalte aus?
Der Name, der Typ und die Werte.
Also baust du eine Tabelle, die die reine Definition beinhaltet

Columns
- ID
- Name
- DataType
- NotNull

ColumnValues
- ID
- ColumnId
- Value

Welche Typen du für die Spalten der beiden Tabellen nimmst, musst du dir überlegen. Text ist für den Wert sicher angebracht, weil du da alles rein hauen kannst und ich nicht weiß, ob es auch eine untypisierte möglichkeit gibt.
An sich gibt es noch XML, aber ich denke, es sollten wenn dann nur einzelne Werte gespeichert werden, das ist einfacher.

Dennoch solltest du dir das genau überlegen und nicht (!) so übernehmen.
Wir nutzen das Prinzip auch so, allerdings mehrfach für einzelne Bereiche, damit wir trotzdem genau wissen, was als Wert stehen kann. Wir haben auch nur Text-Daten und die werden auf Business-Seite entsprechend validiert.

Erst mal vielen Dank für die Erklärungen.

Ich denke ich habe mich für eine Mischform entschieden.
Einige der Felder kommen standardmäßig vor. Diese sind auch die wichtigsten, die zur Suche genutzt werden könnten.

Also werde ich versuchen, eine Tabelle zu machen, die die festen Felder hat und dann ein Feld XML. In diesem sind dann alle anderen Felder und deren Deklaration enthalten, so dass ich daraus auch die Oberfläche aufbauen kann.

Also soweit die Theorie. Ich sehe mich schon Monate lang verzweifelt nach Informationen suchen um die 1314 Zeilen Code zu schreiben
Aber es scheint mir die Aufgabe jetzt klarer vor mir zu liegen und ich hoffe mit dieser Tabelle einen gangbaren Weg einzuschlagen.

Warum XML?

Was ist, wenn du mal etwas am Konzept ändern möchtest, erweitern, was auch immer?
Du müsstest jedes XML-Dokument durch gehen und das an passen.

Wenn du eine normalisierte Datenbank hast, dann hast du das Problem eher selten bis gar nicht.


Ich weiß nicht, was du vor hast, aber ich kann dir aus eigener Erfahrung und stellvertretend für meine Kollegen sagen:
Gehe nicht den einfachen Weg, weil er einfacher ist, sondern weil er besser ist.

Das klingt so, als würdest du kein Konzept finden, das passen könnte und nimmst deshalb der Einfachheit wegen XML, was sich leicht von C# aus generieren lässt.


Außerdem ist mein Beispiel nur ein Beispiel, das kann endlos weiter gemacht werden.

So könntest du z.B. eine Tabelle erstellen, die die Daten zu einem Control beinhaltet, sowie eine Spalte, die das Parent-Control angibt.
So kannst du beliebige Verschachtelungen bauen. Dann noch eine Tabelle, die einen Key von der Control-Tabelle beinhaltet und dazu Name und Wert von Eigenschaften.
Auf diese Weise hast du dann auch gleich noch die Eigenschaften zu Controls unter gebracht.

Das könntest du ewig so weiter treiben, es ist da sinnvoller, sich auf den benötigten Bereich zu beschränken, aber es ist auf jeden Fall besser, als XML in einer Datenbank.



So und wenn nun ein anderes Foren-Mitglied hier anderer Meinung ist, möge er das gerne kund tun, aber ich halte XML in einer Datenbank für nicht sinnvoll.
Höchstens dann, wenn das Format der Daten sich regelmäßig auf so verschiedene Weise ändern kann, dass es schlicht zu viel wäre, das alles mit Tabellen abzudecken.

Ich kann ja die Software noch mal genauer beschreiben, denn ich habe sie schon einmal soweit programmiert das grundsätzlich alles funktioniert hat.

Leider wurde sie von der Klientel nicht angekommen. Zu kompliziert und zu starr. Wie schön, Monate umsonst programmiert . . .

Gut, also es geht im Prinzip um ein Protokoll. Die Max. Ausbaustufe bisher gliedert sich folgende Punkte
2 erster Ordnung
3 dritter Ordnung
Hier habe ich mal gezählt
insgesamt 19 vierter Ordnung
und 120 fünfter Ordnung
2 zweiter Ordnung
7 Dritter Ordnung
in der zweiten Abteilung habe ich die Details nicht gezählt, ist aber ähnlich wie oben.

Die Punkte haben zum Teil Textfelder und zum Teil Textfelder mit der Möglichkeit vorgefertigte Antworten einzufügen und diese gegebenenfalls zu ergänzen.

Zu kompliziert war es, weil ich Kunden, Orte und Patienten jeweils in einer eigenen Form untergebracht hatte. So konnten alle drei beliebig und auch variable miteinander verbunden werden. Ging dann bei der Erhebung recht einfach, musste eben nur korrekt angelegt werden.

Zu starr war es, weil diese Monster Fragekataloge zwar die "Amtliche"-Vorgabe sind, die alten Hasen aber davon nur einen Bruchteil verwenden.

Daraus resultierte für mich die Überlegung.
Die neue Version muss ganz einfach aufgebaut sein, keine extra Datenhaltung für Kunden, Orte und Patienten, aber nach allen muss man suchen können so wie nach dem Datum der Erhebung.

Außerdem will ich sie in WPF machen, zum einen wegen der möglichen Portierung auf WP oder W8 MUI, zum anderen weil ich dann die Oberfläche so gestalten kann, dass sie gezoomt automatisch größere Schrift bringt. Für die alten Hasen deren Augen schlechter werden.

Jeder Nutzer muss sich also seinen Fragekatalog selber anpassen können, beziehungsweise das bei mir beauftragen können, daraus muss sich automatisch die Oberfläche erstellen. Außerdem muss man an den Katalogen Änderungen vornehmen können und die Software muss das tolerieren und zu den alten Katalogen kompatibel bleiben.
Also nicht anpassen der Datenbank nach Änderung des Katalogs, sondern eine Datenbank und eine Oberfläche die sich anpasst.
Werden alte Daten aufgerufen wird die entsprechende Oberfläche gezeigt, bei neuen gegebenenfalls eine andere.

Ein XML Feld schien mir tatsächlich aber auch eingängiger, weil ich bei Deinem System gedanklich nicht den Schritt von Zeile zu Spalte geschafft habe. Klingt sicher lächerlich aber ich verstehe halt nicht wie ich eine indexierte Spalte aus einem Haufen Zeilen heraus bekomme.

Bei dem XML Feld Konzept hatte ich auch einige Ratschläge von einem befreundeten Programmierer der natürlich auch sagte, frag drei Programmierer bekommst Du fünf Wege aufgezeigt und bei seinem "ich zeig Dir mal wie son Model aussehen könnte" Funktionen verwendet hat die zu lernen alleine ein Monat dauern wird

Du siehst zum einen meine Beweggründe und zum anderen auch das eben mein schwaches Programmier-Niveau es mir schwierig macht einen Weg auszuwählen. Für mich sind das alles Dinge die ich mir schwer erkämpfen muss, habe wenig Zeit zum Programmieren und es auch eher nebenbei gelernt als das ich eine fundierte Ausbildung hätte.

Den Weg normale Tabelle mit XML Feld kann ich mir ungefähr vorstellen, auch wenn ich keinen Plan habe was enum ist, wie man serialisiert, oder wie ich aus dem XML Feld dann eine Oberfläche aufbauen soll und das auch möglichst noch relativ schnell usw. usw.

So Roman geschrieben und eher genervt davon das ich nicht mal so ne simple Datenbankanwendung planen geschweige denn programmieren kann

Vorneweg: Das Planen einer Anwendung ist meiner AUffassung nach das mit Abstand Schwierigste an der ganzen Programmier-Arbeit.


Deinen Anwendungsfall habe ich leider immer noch nicht ganz verstanden, meinst du soetwas wie einen Baum?



Wenn du das meinst, dann gebe ich dir Recht, da ist XML tatsächlich im ersten Moment einfacher zu nutzen.
Wenn das allerdings zur Laufzeit von dem Nutzer geändert werden können soll, musst du entscheiden, was das ist. Einstellungen, Designs, etc. würde ich entweder in Form von XML (oder einem anderen Format) auf der Festplatte unter bringen, wenn das nur einfache Einstellungen sind, sind die aber wichtig für die Nutzung, dann würde ich das wiederum in eine Datenbank legen. Unter gewissen Bedingungen würde ich das einfache Design oder Einstellungen auch in eine Datenbank legen, denn dann kann ich z.B. auch ein Mehrbenutzer-System für verschiedene Clients mit zentralen Datenbank-Server implementieren. Du musst auch überlegen, wie viele Daten du hast und was du damit machst. Wenn es Wenige sind und du nur von Oben nach Unten einlesen musst, dann wird XML vermutlich schneller sein, wenn es aber sehr viele Daten sind und du darin auch mal Teile suchen musst, dann wirst du starke Performance-Probleme mit XML haben, da du da nicht effektiv suchen kannst.

All das musst du dir sehr genau überlegen, angefangen mit den Anforderungen.

Es gibt da so das Stichwort Lastenheft. Der Kunde schreib auf, was er sich von der Software erhofft und setzt sich dann mit dem Entwickler zusammen. Der schreibt danach ein Pflichtenheft, das im Idealfall alle Anforderungen aus dem Lastenheft enthält. Es gibt an, was der Entwickler umsetzen wird und daher muss das so detailliert wie möglich sein. Bevor das nicht steht, wird keine Zeile Code geschrieben.

Wenn das dann alles funktioniert hat und Beide zu einer Einigung gekommen sind, dann kann der Entwickler sich hin setzen und die Anforderungen aus dem Pflichtenheft aufteilen, in einzelne Punkte.
Wir nennen diese Punkte User Stories, da steht drin, was ein Teil der Gesamt-Anforderung können soll und das genau beschrieben. Wie das umgesetzt wird, gehört da nicht rein.
Danach kann der Entwickler Tasks definieren um die ANforderungen aus den User Stories umzusetzen, wo dann genau beschrieben wird, wie es gemacht werden soll.



Den Spruch "frag drei Programmierer bekommst Du fünf Wege aufgezeigt" kenne ich im Übrigen auch, schön aus dem Leben gegriffen. ^^
Allerdings solltest du das als Vorteil betrachten, denn Keiner kann alles wissen und Jeder lernt immer von Jedem. Deshalb gibt es Foren darüber.

XML zu serialisieren ist denkbar einfach, dafür gibt es eine fertige Klasse. Es gibt auch noch einige andere Wege, die sind aber komplexer.
Für den einfachen Weg musst du allerdings Klassen schreiben, die deine Daten so darstellen, wie du sie gespeichert haben willst. Eine in sich verschachtelte Klasse könnte z.B. so aus sehen:



In so einem Fall würde ich dann aber ein Basis-Interface bauen:



Wenn du das hast kannst du erst einfach und ohne viel Code zu XML serialisieren, aber wenn du das hast, dann kannst du auch relativ einfach die Datenbank-Tabellen ableiten:




So ungefähr könnte das aus sehen, muss aber nicht.
Das ist nur ein Beispiel, was ich gerade zusammen geschrieben habe, sicher gibt es bessere Varianten, die Regel mit den drei Programmierern und fünf Lösungen gilt auch hier. ^^

Ich bin etwas von dem Thema abgekommen, möchte mich aber für die hilfreichen antworten bedanken.
Habe das erst mal weiter verschoben und versuche mich an einfacheren Dingen.

Versuche mich durch die Universal Apps zu kämpfen und hoffe das wir bald Modern UI Porgramme im Fenster auf dem Desktop benutzen können, dann muss man nicht noch eine Windows Desktop App zusätzliche schreiben

Jedenfalls habe ich den Thread in meinen Unterlagen für das Programm gespeichert und sollte ich die Arbeit daran wieder aufnehmen, weil ich mich dem gewachsen fühle kann ich Eure Ratschläge nutzen.