verschiedenartike Daten in einem DataSet speichern, oder in mehreren

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von DerSmurf.

    verschiedenartike Daten in einem DataSet speichern, oder in mehreren

    Guten Morgen
    Vor kurzem habe ich hier gelernt wie ich eine xml Datei hinter meinem DateSet mit Passwort und Salt verschlüsseln kann, um sensible Daten zumindest relativ sicher auf Platte abzulegen.
    Nun stellt sich mir die Frage, wohin mit meinen restlichen Daten.
    In Zukunft (Programm steht noch am Anfang) werde ich folgendes in einem DataSet speichern:
    • Adressbuch (ca. 200 Einträge)
    • Wenn ich es hinbekomme meine empfangenen Mails (ich gehöre zu den Menschen die nie Mails speichern, sondern immer nur deren Daten - aber je nach User variiert die Menge der Mails ja starkt)
    • Bestellungen bei Firmen - also Bestelldatum, LIeferdatum, Rechnungsnummer, Rechnungssumme, usw. (derzeit 54 Firmen - Bestellrhytmus maximal 1x pro Woche, bis 2 - 3 mal im Jahr - also sagen wir mal 2.000 Einträge pro Jahr)
    • Infos über Artikel (Art. Nr, Ek, Vk, Mwst, Marge, Name, Lieferant, EAN, usw) - derzeit ca. 30.000 Zahl langsam wachsend
    • Kundenbestellungen (seid 2017 sind es ca. 600 Stück)
    • und dann Kleinkram - emailzugangsdaten, usw. also nichts was Mengenmäßig eine Rolle spielt
    Die Artikelinfos werde ich in ein eigenes DataSet schreiben, damit ich dieses leicht auf mehereren Rechnern aktuell halten kann (wobei natürlich nur ein PC die Daten bearbeitet).

    Aber wohin mit den anderen Daten? Alles in ein DataSet, oder erreiche ich eine bessere Performance, wenn ich die Dateien in eigene DataSets schreibe, weil ich dann schnellere Zugriffszeiten, oder sowas erreiche?

    edit: einen Kalender soll es in später Zukunft auch noch geben. Hier habe ich aber noch überhaupt keinen Plan wie die Umsetzung erfolgen soll (ist aber eh noch Zukunftsmusik),

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DerSmurf“ ()

    Ich teile @Murdoc's Bedenken. Es muss halt klar sein, dass Du beim DataSet immer alles im Arbeitsspeicher vorhältst. Bei einer Datenbank hängt es von der Abfrage ab, was Du im Speicher hast.
    Solltest Du auch Kundendaten von natürlichen Personen vorhalten, musst Du Dich zudem noch um DSGVO Konformität bemühen, die sieht eine Verschlüsselung der Datenbank vor.
    Alles in eigene Datsets zu unterteilen ist alerdings wenig sinnhaft, mal vorsichtig ausgedrückt.
    Ich würde auch zu nem MS SQL Server tendieren. Die Verdrahtung mit Visual Studio ist da top und bei der "kleinen" Datenmenge würde ich sagen, reicht die kostenfreie Variante dicke.
    Damit hast auch gleich die Möglichkeit mit zich Usern gleichzeitig an den Daten zu arbeiten, schränkst dich also für die Zukunft nicht ein.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D
    Hallo
    Ich habe eigentlich nicht vor, die Daten mit anderen Usern zu teilen, da meine Frau und ich die einzigen sein werden, die das Programm verwenden.
    Und dies auch nur auf einem PC.
    Das einzige wären dabei, wie im eingangspost erwähnt, die Artikelinfos Wenn ich diese einfach hin und herschieben könnte, wäre das hübsch.
    Damit sie auch auf ihrem Arbeits PC Artikeldaten einsehen kann. Wenn dies nur unregelmäßig aktualisiert wird, wäre es aber vollkommen ausreichend.

    Wichtig ist (das hab im Eingangspost vergessen), dass die gesamte Anwendung offline läuft.

    Ansonsten weiß ich nicht, was eine lokale Datenbank besser macht als ein DataSet (also keine Ironie - weiß ich echt nicht).
    Und ebenfalls habe ich keine Ahnung über die Limitationen von DataSets. Also ab welchen Datenmengen macht es keinen Sinn / Spaß mehr.
    Alles was Du da schreibst, geht auch mit DataSet. Wenn aber, würde ich zusehen, die tDs auf eine, wenn es nicht anders geht (mit vertretbaren Aufwand für Dich), dann halt zwei.
    Es kommt ein wenig drauf an was genau Du machst, und von tDs auf Datenbank zu gehen ist nicht das größte Problem. Zu dem hat @ErfinderDesRades auch einen speziellen Artikel zu geschrieben.
    Also fang ruhig mit tDs an, wenn Du in ein paar Jahren auf eine Datenbank migrieren willst, geht das auch. 30 Tsd Datensätze sind auch noch kein Problem, die PCs werden immer schneller und der Arbeitsspeicher ist sicher auch locker ausreichend. Ich habe auch schon mit mehr als 300 Tsd Datensätzen im tDs gearbeitet, das wird dann aber doch schnell zäh und macht definitiv keinen Spaß mehr.

    DerSmurf schrieb:

    Die Artikelinfos werde ich in ein eigenes DataSet schreiben, damit ich dieses leicht auf mehereren Rechnern aktuell halten kann (wobei natürlich nur ein PC die Daten bearbeitet).


    Da du von mehereren Rechnern gesprochen hast, habe ich zur Datenbank Variante geraten. Wenn es de facto nur ein PC ist, kannst du auch nur mit Datasets und XML arbeiten.
    Wie @Dksksm schreibt, kannst du später immernoch auf eine DB umstellen. Generell sollte man die Skalierbarkeit immer im Blick haben und nicht nur den IST-Zustand.

    Es spricht für mich nichts dagegen, für alle Daten ein Dataset zu verwenden - in der DB Variante wäre es auch nur eine Datenbank.
    Gruß Murdoc
    Naja, ich verstehe das mit den Artikeln noch nicht recht.
    Geht's da nur um ne Importfunktion\Export für Artikeldaten?! Ich stehe etwas auf dem Schlauch wo das gedankliche Problem ist.
    Wenn es nur einen PC gibt, dann kann doch da jeder die Artikeldaten sehen. Oder soll jetzt doch von einem zweiten Rechner auf das Dataset zugegriffen werden?
    Wenn ja, ist der PC solange an? Dann ist das ja kein Problem. Dann darfst du nur den Pfad zur XML nicht fix machen, sondern musst ihn konfigurierbar machen, sodass PC 1 auf seine lokale XML und PC 2 auf die im Netzwerk erreichbare XML zugreift.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D
    Huhu. Irgendwie funktioniert die THread Benachrichtigung gerade nicht so ganz.

    Also. Alle Daten sollen nur auf einem PC verwendet werden.
    MIT EINER AUSNAHME. Den Artikelbestand möchte ich in unregelmäßigen auf EINEM weiteren PC aktualisieren.

    Bisher ist es so, dass mein Warenwirtschaftsystem eine Exportfunktion hat.
    Hiermit hohle ich mir einen aktuellen Warenbestand im Excel Format.
    Diesen kopiere ich alle paar Wochen mal auf den PC meiner Frau, damit sie dort aktuelle Artikelstammdaten hat.

    Genau dies möchte ich realisieren, indem ich dann einfach die xml Dateu auf ihren PC kopiere.
    Also kann ich ja problemlos alle Daten in ein DataSet klatschen, außer die Artikelstammdaten, welche ein eigenes DataSet erhalten.
    Wenn @Dksksm bereits mit DataSets mit über 300.000 Einträgen gearbeitet hat, dann sollte es ja bei mir problemlos, viele, viele, Jahre laufen.
    Wenn ich das Wachstum meiner Datensätze so hochrechne, würde mein Programm ca. 80 Jahre brauchen, um die 300.000 Einträge zu erreichen.
    Und wir wissen ja nichtmal ob dann Schluss ist.

    Also kann ich ja problemlos mein DataSet verwenden und sollte ich 120 Jahre alt werden, schau ich mir an, wie ich das ganze in eine Datenbank bekomme.
    Ich sehe eigentlich keinen Grund das getrennt zu lagern. Bau halt auch wieder ne Export und ggfs. Importfunktion. Oder ermögliche Ihr die XML einzulesen. Dann hat sie ja ne lokale Kopie aller Daten. Wenn du alles als Dataset in ne XML speicherst, kannst die XML ja auch kopieren, wenn du sie nicht per Freigabe erreichbar machen willst. Da hast ja alle Möglichkeiten.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D
    Ja, ich vermute, dass ich später ohnehin eine Exportfunktion basteln muss, in der ich nur bestimme Spalten exportiere.
    Zur Zeit nutze ich einen solchen Export um zum Beispiel eine LIste für die Angestellten zu erstellen, um mittels Barcode einen Preis nachzuschauen.
    In einer solchen Liste hat natürlich ein Einkaufspreis z.B. nichts zu suchen.

    Aber ich dachte mir, für mich und meine Frau, sei es am einfachsten einfach die xml auf einen Stick zu ziehen und bei ihr auf den PC rüberzuschubsen.
    Das HauptDataSet (also das was die Daten AUßER der Artikelstammdaten enthält) ist das verschlüsselte (Passwort und Salt) und dieses enthält auch Daten die ich nicht kopieren möchte / also z.B. gespeicherte Adressen. Diese möchte ich natürlich bei meiner Frau nicht überschreiben.

    Daher dachte ich mir, die Artkelstammdaten (also nur die zu kopierenden Daten) als eigenes DataSet in eine eigene xml, wäre der leichteste Weg.
    Aber Export / Import ist natürlich ebenfalls denkbar (und für mich realisierbar)

    Nur kann ich leider nicht beurteilen wie "schlimm" es ist zwei DataSets zu haben.
    Also hat es für mein Programm gravierende Nachteile, wenn ich zwei DataSets anbinde?

    Meine Überlegung hier war, dass ich ja damit die Datenmenge auf die ich zugreife etwas kleiner halte.
    Also wenn ich z.B. auf die Adressen (DataSet1) zugreife, ist zawr DataSet2 auch im Speicher geladen, aber da greife ich ja nicht drauf zu.
    So ist für mich (in meiner Welt xD) logisch, dass es mit 2 DataSets schneller geht.
    Aber das stimmt wohl nicht?