VB.net mit Datenbank (Einkaufskorb)

Computer: Software & Programmierung .NET & C#
#1

Guten Tag,

Ich stehe gerade vor einer kleinen Krise… folgende Ausgangslage: Ich habe ein Programm mit VB.net geschrieben mit dem sich gewisse DataTables aufrufen und bearbeiten lassen. Ich habe mehrere DataTables (ca. 1000)  die gewisse Objekte darstellen, z.B. Paket X und Paket Y, nun möchte ich eine Art Auswahl bieten, bspw. mit Ja/Nein-Felder, mit der, wie mit den bekannten Web-Einkaufskörben, die Pakete X und Y aus- bzw. abgewählt werden können um am ende das Produkt Z zu haben (Neu erstellte Datenbank?) und dieses weiter zu verwenden (Zur Auswertung). Nun zu meiner Frage: Wie lässt sich das ganze realisieren? Lassen sich die Ausgewählten Tables komplett selektieren/kopieren, whatever, und mit Zusatzwerten in einer Art Einkaufskorb speichern? Hat sich zufällig schon mal jemand damit beschäftigt und hat ein Codebeispiel für mich?

Vielen Dank!

#2

Hallo ?,

verstehe nicht so ganz, was du möchtest.
Soll das eine Web-Anwendung werden?
Und eine Frage: Hast du tatsächlich 1000 DataTables? Oder eine DataTable mit 1000 Zeilen sprich Produkten?

Egal. Jedes Produkt dürfte ja so etwas wie eine ID haben. Sobald der User ein Produkt auswählt, die ID in einer Liste vermerken. (z.B. einfach ein Array, meinetwegen mit 1000 Elementen, da gibt esbestimmt was dynamischeres…)

Wählt der User ein Produkt ab, die ID löschen.

Die Basistabellen werden nur dann benutzt, wenn man die Attribute eines Produktes benötigt.

fg

Dirk.P

#3

Hallo Techs,

ich stimme Dirk.P zu. Egal wie du die einzelnen „Pakete“ auswählst oder verwaltest brauch du für die endgültige Zusammenstellung eine geeignete Liste. Quasi einen endgültigen Einkaufskorb. Ob das dann einfach nur ein Array mit IDs ist oder eine eigene Datenbank die alle Informationen der einzelnen Paket beinhaltet, bleibt dir und deinem Programm vorbehalten.
Denke aber daran die Datenverarbeitung schlank, einfach und redundanzfrei zu halten. Ein Array oder eine List(of T) halte ich hier für sinnvoller.

MfG
GuerillaDenker

#4

Vielen Dank für eure Antworten!

Nein, es soll eine reine Offline-Anwendung werden, und ja, es sind (ca.) 1000 Tables mit jeweils 10-1500 Zeilen, deswegen hatte ich gehofft dass es eine elegantere Lösung gibt als rund 700000 ID’s neu zu vergeben (Weil die ID’s in jedem Table wieder bei 1 beginnen notwendig, oder Denkfehler?)

MfG
Tech

#5

Hallo Techs,

dann bau die halt einen Key:

Key = DataTable.Name & „_“ & ID

Ich hoffe mal, dass deine DataTable names kein „_“ enthalten. Sonst must du halt einen anderen Trenner nehmen.

Die Kombi dann in der Liste merken.

fg

Dirk.P

#6

Ich verstehe nicht genau, was du tun willst. Wenn du nur Informationen speichern willst, welche der Pakete X, Y, etc. für das fertige Produkt Z ausgewählt sind, dann speichere nur IDs dieser Pakete in einer Liste und nicht die gesamten Objekte. Aber ehrlich gesagt habe ich keine Ahnung was du genau tun willst…

#7

Hi,

ändern sich die einzelnen „Pakete“/DataTables??
Wenn nicht, dann brauchst du für die Zusammenstellung nur eine ID oder einen sonstigen Identifikator um die jeweiligen Tables eindeutig zu identifizieren. Ob das ein Name ist oder eine ID ist dabei egal (ID bevorzugt).

Ich weiß auch immer noch nicht so genau was du da überhaupt machen willst aber ich persönlich würde die einzelnen Tables eindeutig identifizierbar machen und im „Einkaufskorb“ :smile: nur den jeweiligen Identifikator der Tabelle hinterlegen.
Anschließend kannst du dann problemlos über den „Einkaufskorb“ auf die Table-ID und dann auf den Inhalt des DataTables kommen.

Ohne das du deine Idee hier im Detail erläutern musst würde mich aber dennoch grob interessieren was für ein Programm das werden soll und was die DataTables darstellen und beinhalten… Da du ja schon am Anfang von Paketen, Produkten und Einkaufskörben gesprochen hast, stelle ich mir persönlich eine Art Katalog, Konfigurator, Shop oder Kassensystem vor… Wie weit weg bin ich mit meiner Vermutung??? :wink:

MfG
GuerillaDenker

#8

Hallo,
also meine Erfahrung sagt mir, wenn du über 1000 Tebellen hast, dann stimmt der ganze Ansatz schon mal nicht, egal was du vor hast. Du hast scheinbar das Konzept von relationalen Datenbanken noch nicht verstanden oder du hast wirklich eine Anwendung die so unwarscheinlich ist, das da noch nie jemand drauf gekommen ist.
Wie auch immer, irgendwie weiss hier niemand so recht worauf du hinaus willst und da wird es einfach schwierig dir zu helfen.

mfg
 Thomas

#9

Ich weiß, dass es, bei dieser geringen Menge an Informationen, schiwerig ist mir zu folgen, aber eure Anregungen und Lösungsansätze haben mir erst mal sehr weiter geholfen. Vielen Dank!

@ GuerillaDenker: Ja, die Tables ändern sich, es gibt eine Reihe von „Standardpaketen“ die regelmäßig angepasst werden und zusätzlich eine Art manueller Verbesserung der „Standardpakete“ als zusätzliche Option. Und ja, du liegst garnicht so falsch, es soll eine Art Konfigurator werden.

#10

Hi Techs,

ok dann folgender Ansatz:

  • Grundsätzlich schreibst du in deine Einkaufsliste die ID der Tabelle und die ID des jeweiligen Datensatzen (Im Sinne von „Kategorie und Produkt // Table-ID und Dataset-ID“). Dann hast du auf jedenfall schon mal alle Grundinformationen zusammen ohne Redundant zu werden.
  • An den Tabellen selbst kann sich nicht viel ändern. Entweder es kommen Tabellen oder Datensatz hinzu bzw. weg oder es ändern sich Inhalte innerhalb eines Datensatzes.
    Kommt eine Tabelle oder ein Datensatz weg, musst du dich entscheiden ob du diese dann auch komplett löscht oder nur ein „Inaktiv/Gelöscht“-Flag irgendwo in die Tabelle bzw. in den Datensatz setzt (je nachdem ob Tabelle oder Datensatz).
    Beim einen findet der Anwender keine Informationen mehr, beim andern hat er noch Informationen aber darf damit nichts mehr anfangen.
    Ändern sich aber die Inhalte (abhängig vom Benutzer bzw. der Einkaufsliste), würde ich zusätzlichen (und nur dann) die geänderten Informationen in die Einkaufsliste schreiben.

Grundsätzlich muss ich dir aber leider sagen das Thomas Stoll irgendwohin recht hat. Bei so einer Menge an Daten und der Möglichkeit an zusätzlichen User-eigenen Änderungen, solltest du evtl. doch nochmal über das Konzept nachdenken.

MfG
GuerillaDenker