ich brauch jetzt das erste mal eine kleine Datenbank in meinem Programm. Genauer gesagt sind es sogar zwei.
Eine mit etwa 20 Datensätze und eine etwas größere mit etwa 200 Datensätzen.
Hinzu kann ich noch sagen das die Einträge geändert werden können, jedoch der User nie die Datenbank zu gesicht bekommt sondern nur einzelen Inhalte.
Kann mir jemand Infos geben oder mir sagen wo ich welche finde. Danke! 🙂
Äh...da ist ne Datenbank fast overkill.
Vielleicht die Daten komplett im Speicher halten (List<T>) und als XML serialisieren?
moin
bei diesen anforderungen ist xml wahrscheinlich die bessere lösung jedoch könnte auch dBase Dateien deinen anforderungen entsprechen
Ich dachte das es sich mit einer Datenbank am besten lösen lässt lass mich aber gern vom Gegenteil überzeugen.
Kommt halt drauf an, was Du mit den Daten machen willst:
Sind es Settings oder Nutzdaten?
Willst Du Queries drauf laufen lassen (z.B. Suchen)?
Statt dBase würd ich SqLite empfehlen, ist aber Ansichtsache 🙂
greetz
DaSchroeter
Das ist ungefähr so, als transportiert man seine Einkäufe von ALDI mit nem 16-achsigen Tieflader nach Hause....
Vermutlich eine typische Baustelle für XML...
Original von svenson
Das ist ungefähr so, als transportiert man seine Einkäufe von ALDI mit nem 16-achsigen Tieflader nach Hause....
LOL! Kann ich mir das ausborgen?
Wirklich treffend ausgedrückt! 🙂
was willst du denn wisen
wie du darauf zugreifen kannst --> per zb oledb
brauchst nur connection string --> solltest da fündig werden
http://www.connectionstrings.com/
oder was anderes ?
wie du es nun machst bleibt dir überlassen
ich würde die XML variante wahrscheinlich vorziehen (kommt halt auf den anwendungsfall an)
mfg
hallo Maus,
sollen sich denn die User deines Programms (im Falle von mehreren) die Nutzdaten teilen, oder bekommt jede Intallation seine eigenen Daten? Wenn jede User mit jeder Installation seine eigenen Daten bekommt, dann würde ich Dir auch zu XML raten. Du könntest dich auch einer DataTable bedienen, die du jeweils beim öffnen und schließen deiner Anwendung aus einer XML-Datei lädst, bzw. speicherst. So müsstest Du dich nicht um XML kümmern und könntest wie bei "normalen" Datenbankandwendungen agieren.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Original von blackcoin
moin... jedoch könnte auch dBase Dateien deinen anforderungen entsprechen
dBase ist tot. Wer das in neuen Projekten einbaut, dem gehört ein Schlag ins Genick. Bitte nicht persönlichen nehmen, blackcoin. 😉
Wenn mehrere Benutzer gleichzeitig zugreifen, würde ich immer den SQL Server verwenden (auch bei 5 Datensätzen). Da habe ich keine Probleme mit Multiuser-Zugriff oder Transaktionssicherheit, da der SQL Server das alles schon kann. Außerdem ist er ist einfach zu verwenden und in der Express-Version kostenlos.
XML ist recht für Konfigurationsdateien oder für Dokumente, die mit anderen System ausgetauscht werden sollen. XML ist aber niemals eine Datenbank. Mach Dir mal den Spaß und suche mit drei Threads gleichzeitig irgendeinen Knoten in einer XML-Datei.
Wenn Deine Anwendung in 2 Jahren 5000 Datensätze hat, weil sie intensiv genutzt wird und Du sie inziwischen weiterentwicklet hast, wirst Du froh sein, gleich den Tieflader genommen zu haben. Das nennt man Skalierbarkeit. Selbst mit 2 Mio Datensätzen in einer Tabelle müsstest Du gar nichts an Deiner Architektur ändern. Die Anwendung wäre immer noch so schnell wie eh und je (Da der SQL Server die Datenabfrage mit Indizes optimiert). Und wenn die Server-Hardware dick genug ist, können hunderte Benutzer gleichzeitig mit Deiner Anwendung arbeiten. Ob Du das jetzt brauchst oder nicht; Besser ist, Du kannst es, wenn Du es brauchen solltest.
@Rainbird
XML ist recht für Konfigurationsdateien oder für Dokumente, die mit anderen System ausgetauscht werden sollen. XML ist aber niemals eine Datenbank. Mach Dir mal den Spaß und suche mit drei Threads gleichzeitig irgendeinen Knoten in einer XML-Datei.
Also so stimmt das ja nun auch nicht: Erstelle in der Anwendung ein Dataset mit DataTables und Constraints/PrimaryKey; dann kannst Du mit WriteXml und ReadXml das Ganze wie in einer "richtigen" Datenbank benutzen.
Zum Datenumfang: Andreas Kosch hat mir bestätigt, dass eine solche "Datenbank" bei read-only (nämlich als lokale Kopie der PLZ-Ort-Datei) auch mit 30 bis 100.000 Datensätzen noch sinnvoll ist.
Voraussetzung muss natürlich die Single-User-Verwendung sein.
Meine Empfehlung lautet also: nicht puristisch entscheiden, sondern je nach Situation.
Gruß Jürgen
Original von juetho
Voraussetzung muss natürlich die Single-User-Verwendung sein.Meine Empfehlung lautet also: nicht puristisch entscheiden, sondern je nach Situation.
du sprichst mir aus der Seele juetho.
Original von Rainbird
Wenn Deine Anwendung in 2 Jahren 5000 Datensätze hat, weil sie intensiv genutzt wird und Du sie inziwischen weiterentwicklet hast, wirst Du froh sein, gleich den Tieflader genommen zu haben. Das nennt man Skalierbarkeit. Selbst mit 2 Mio Datensätzen in einer Tabelle müsstest Du gar nichts an Deiner Architektur ändern. Die Anwendung wäre immer noch so schnell wie eh und je (Da der SQL Server die Datenabfrage mit Indizes optimiert). Und wenn die Server-Hardware dick genug ist, können hunderte Benutzer gleichzeitig mit Deiner Anwendung arbeiten. Ob Du das jetzt brauchst oder nicht; Besser ist, Du kannst es, wenn Du es brauchen solltest.
Nicht bei jeder kleinen Anwendung, die auf irgend eine Art und Weise Daten verarbeitet, bedarf es mit Kanonen auf Spatzen zu schießen.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Original von juetho
@Rainbird
Also so stimmt das ja nun auch nicht: Erstelle in der Anwendung ein Dataset mit DataTables und Constraints/PrimaryKey; dann kannst Du mit WriteXml und ReadXml das Ganze wie in einer "richtigen" Datenbank benutzen.Zum Datenumfang: Andreas Kosch hat mir bestätigt, dass eine solche "Datenbank" bei read-only (nämlich als lokale Kopie der PLZ-Ort-Datei) auch mit 30 bis 100.000 Datensätzen noch sinnvoll ist.
Voraussetzung muss natürlich die Single-User-Verwendung sein.
Wenn es sich nur um eine read-only Kopie handelt ist das okay. Aber wenn Datensätze angelegt, geändert und gelöscht werden müssen, sollte man eine richtige Datenbank einsetzen.
Es spielt für mich keine Rolle, ob etwas von einem Spezialisten gesagt wurde, oder von jemanden mit Diplom oder Doktor-Titel oder jemanden ganz unbekannten, der in irgendeinem Forum mit dem Gast-Zugang postet. Wenn seine Argumente besser sind, als meine eigenen, lasse ich mich überzeugen.
Kannst Du mir auch sagen, warum das noch sinnvoll ist und warum es nicht sinnvoll sein soll, einen SQL Server zu verwenden?
Original von Rainbird
Kannst Du mir auch sagen, warum das noch sinnvoll ist und warum es nicht sinnvoll sein soll, einen SQL Server zu verwenden?
Unnötige Abhängigkeit von einer anderen Anwendung, sprich' SQL Server, und höherer Installationsaufwand wenn noch nicht vorhanden, sowie höherer administrativer Aufwand durch erstellen von DB-Skripten bzw. anlegen von Datenbanken und anpassen der Verbindungszeichenfolge.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Ich gebe Dir Recht, wenn es sich nur um Single-User-Zugriff auf die Daten handenlt. Bei Multi-User wäre eine Implementierung mit einer XML-Datei entsprechend aufwändig, was den geringen Installations- und Konfigurationsaufwand des SQL Server bei weiten übertreffen würde (Die SQL Server-Installation ist nicht aufwändig).
_Original von Rainbird_Wenn es sich nur um eine read-only Kopie handelt ist das okay. Aber wenn Datensätze angelegt, geändert und gelöscht werden müssen, sollte man eine richtige Datenbank einsetzen.
Es spielt für mich keine Rolle, ob etwas von einem Spezialisten gesagt wurde, oder von jemanden mit Diplom oder Doktor-Titel oder jemanden ganz unbekannten, der in irgendeinem Forum mit dem Gast-Zugang postet. Wenn seine Argumente besser sind, als meine eigenen, lasse ich mich überzeugen.
Tut mir leid - die folgende OT-Bemerkung muss sein.
Manchmal glaube ich, dass kurze Anmerkungen bewusst falsch verstanden werden. Andreas Kosch hat natürlich niemals gesagt: "Benutze Xml als Datenbank." Er hat mir bestätigt (im Entwickler-Forum): "Eine Tabelle, die z.B. zum Nachschlagen über eine ComboBox ständig lokal benötigt wird und sich auf dem Server nur selten ändert, sollte als lokale Kopie gespeichert werden; dafür ist Xml gut geeignet." Das hat er unter ausdrücklichem Bezug auf die PLZ-Orte-Tabelle mit der von mir genannten Anzahl von Datensätzen gesagt.
Mein Hinweis darauf sollte nur die Angst vor einer größeren Xml-Datei nehmen - sofern die anderen, wichtigeren Aspekte beachtet werden.
Ende OT Jürgen
Es ging aber nicht um caching von Serverdaten in einem DataSet, sondern um die Persistenz von Nutzdaten selbst. Im Falle einer XML-Datei als "Datenbank" wäre kein Server da.
Was das Caching angeht, gebe ich Dir völlig Recht. Postleitzahlen ändern sich nicht oft und es sind auch nicht so viele, dass sie den Arbeitsspeicher der Clients zu sehr beanspruchen würden. Deshalb ist es vorteilhaft, solche Daten z.B. asynchron bei Programmstart abzurufen und in einem DataSet im Hauptspeicher vorzuhalten.
Das hat aber wenig mit der Frage nach einer Persistenzlösung von Maus zu tun.