Laden...

mini Datenbank und eine etwas Größere

Erstellt von Maus vor 17 Jahren Letzter Beitrag vor 17 Jahren 3.120 Views
M
Maus Themenstarter:in
25 Beiträge seit 2006
vor 17 Jahren
mini Datenbank und eine etwas Größere

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! 🙂

215 Beiträge seit 2004
vor 17 Jahren

Äh...da ist ne Datenbank fast overkill.
Vielleicht die Daten komplett im Speicher halten (List<T>) und als XML serialisieren?

2.223 Beiträge seit 2005
vor 17 Jahren

moin

bei diesen anforderungen ist xml wahrscheinlich die bessere lösung jedoch könnte auch dBase Dateien deinen anforderungen entsprechen

M
Maus Themenstarter:in
25 Beiträge seit 2006
vor 17 Jahren

Ich dachte das es sich mit einer Datenbank am besten lösen lässt lass mich aber gern vom Gegenteil überzeugen.

M
Maus Themenstarter:in
25 Beiträge seit 2006
vor 17 Jahren

blackcoin

kannst du mir mehr über bBase Dateien sagen.

Danke!

215 Beiträge seit 2004
vor 17 Jahren

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

S
8.746 Beiträge seit 2005
vor 17 Jahren

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...

M
Maus Themenstarter:in
25 Beiträge seit 2006
vor 17 Jahren

Es handelt sich um Nutzdaten

215 Beiträge seit 2004
vor 17 Jahren

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! 🙂

2.223 Beiträge seit 2005
vor 17 Jahren

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

476 Beiträge seit 2004
vor 17 Jahren

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

3.728 Beiträge seit 2005
vor 17 Jahren
Datenbank

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.

J
3.331 Beiträge seit 2006
vor 17 Jahren

@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

476 Beiträge seit 2004
vor 17 Jahren

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

3.728 Beiträge seit 2005
vor 17 Jahren

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?

476 Beiträge seit 2004
vor 17 Jahren

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

3.728 Beiträge seit 2005
vor 17 Jahren
Kanonen und Spatzen

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).

J
3.331 Beiträge seit 2006
vor 17 Jahren

_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

3.728 Beiträge seit 2005
vor 17 Jahren
Caching

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.