Hallo,

ich versuche zur Zeit eine Bestellsoftware für Items in einem Spiel zu programmieren. Das Problem liegt darin, dass ich einfach nicht weiß, welche Methode sich am besten eignet um alle verfügbaren Items + den Preis + den aktuellen Lagerbestand zu speichern und auszulesen. Das ganze soll über einen Webspace laufen. Am Ende wird es eine Administrationsanwendung und eine Anwendung für den User geben. Wie speichere ich nun am besten die ganzen Werte, so dass sie möglichst einfach und schnell eingelesen werden können und gleichzeitig auch möglichst einfach geändert werden können?

Vielen Dank für eure Ideen im Voraus!
GermanElectronix

Muss man nicht lange drum herum reden: Datenbank. Anbieten würde sich MySQL, MSSQL,...

und auf Client-Seite würde sich ein typisiertes Dataset anbieten, welches dann mittels DataAdaptern zu befüllen wäre.

Daran kannman alle möglichen Controls anbinden, und mit den Controls dann die Daten ändern/löschen/zufügen - was auch immer.
Rückspeichern mit denselben DataAdaptern, die das Dataset auch befüllt haben - das ist sehr effizient, denn Dataset verfügt über eine Änderungsverfolgung, sodass nur tatsächliche Änderungen rückgespeichert werden.

zum anbinden von Controls an typDataset: vier Views-Videos

ErfinderDesRades schrieb:

typisiertes Dataset

Wenn man sich denn unbedingt mit veralteten Technologien abquälen will...

naja - wenn du lauffähige Code-Samples anbringen kannst, die auf den neueren Mapping-Technologien aufbauen - nur zu!

Ich würde auch EntityFramework mehr protegieren, aber das ist nunmal datenbank-gebunden, und unterstützt eiglich nur MS-SqlServer in vernünftiger Weise.
Und typDataset hat den immensen und mehrdimensionalen Vorteil, dass man damit auch völlig datenbank-unabhängig entwickeln kann.

Also ist sehr offen, was die größere Quälerei ist

ErfinderDesRades schrieb:

Und typDataset hat den immensen und mehrdimensionalen Vorteil, dass man damit auch völlig datenbank-unabhängig entwickeln kann.

Was bei sowas komplett irrelevant ist. Weshalb sollte ich mich für etwas altes entscheiden, das etwas kann, das ich nicht brauche. Daten zentral auf Server, mehrere User (bei sowas auch gern ma mehrere hundert) greifen auf gleiche Datenquelle zu. Nunja. Wenn du da irgendwas mit Xml machen willst. Nur zu. Jedoch wirste bei dem ganz schnell auf die Schnauze fallen.
Codesamples gibt es mehr als genug im Netz, zudem hat Entity Framework den Vorteil, dass es weiterentwickelt wird, voll und ganz Linq unterstützt, die Linq Expressions auch in entsprechende SQL Abfragen konvertiert und somit ne recht gute Performance zu Stande bringt (bis auf Initialisierung vll. -> ansonsten sind ja Caches,... vorhanden).
Achja. MySQL wird ebenfalls unterstützt. Hab das sogar bereits ausprobiert. Zwar nicht intensiv getestet, hat aber einen guten Eindruck gemacht, SQL Abfragen wurden richtig generiert, Prozeduren und Views haben ebenfalls tadellos funktioniert. Kurz: Hat nen guten Eindruck gemacht.
Dataset mag seine Daseinsberechtigung haben, jedoch garantiert nicht für solch einen Anwendungsfall. Verstehe auch deine Datenbankphobie nicht.

du verstehst den Vorzug von db-unabhängiger Entwicklung nicht, weil du ihn nicht kennst - deine Sache.

thefiloe schrieb:

Codesamples gibt es mehr als genug im Netz,

Warum aber ist mir kein einziges bekannt, was ich ebenso wie meine eigenen Übungen einfach mal downloaden und starten kann?
Also du hast sicher zig davon an der Hand - könntest du mir zumindest ein paar davon mitteilen?

Ich mache nie kleine Codesamples, da diese hier so oder so keiner anschaut, durchliest, was auch immer. Ich habe nur größere Projekte (hauptsächlich alte Projekte für Firmen, welche ich alleine schon wegen der Geheimhaltung nicht hochladen darf) welche den Rahmen sprengen würden. Du kannst mir aber kaum sagen, dass du keine Beispielcodes zum Entity Framwork im Netz findest. Es gibt tausende Artikel, Blogs, ... wo das alles Behandelt wird.

Ach ja. Ich kenne sehr wohl die Vorteile von db-Unabhängigkeit. Nur übersiehst du folgendes:

msdn schrieb:

Entity Framework ist Datenbank-unabhängig.

Und was das Speichern als Xml angeht... das ist für viele Anwendungsfälle einfach gänzlich ungeeignet. Eine Datenbank kann nunmal viel mehr als eine simple Xml Datei. Das wirst selbst du zugeben müssen. Spätestens wenn viele Benutzer auf eine Datenquelle zugreifen, die Datenbank einen gewissen Umfang übersteigt, entsprechend viele Datensätze angelegt werden, es um Transaktionen, Locks, Prozeduren, Trigger, Zugriffsberechtigungen etc. geht steigt dir jedes Dataset aus.

Aber wie meistens ist jegliche Argumentation bei solchen Themen nahezu sinnlos. Du beharrst auf deinem Dataset, während ich sage, dass man die Technologie auf Basis der Anforderungen wählen sollte. Solange du nicht die Chance bekommst bei Google sämtliche Datenbanken durch Xml Datasets umzustellen... ist mir das recht wurscht ;).

thefiloe schrieb:

Ich mache nie kleine Codesamples, da diese hier so oder so keiner anschaut, durchliest, was auch immer.

Du irrst dich gewaltig. Mit der Zeit downen doch so einige zig oder gar hundert das eine oder annere Sample von mir.
Und wenn du eins zum Thema EF machen würdest: Zumindest ich wäre der erste und begeisterte, ders downen und durchchecken würde, und wenns auch nur annähernd brauchbar ist würde ich auch andauernd drauf verlinken - glaub mir.

thefiloe schrieb:

Du kannst mir aber kaum sagen, dass du keine Beispielcodes zum Entity Framwork im Netz findest.

Naja, was ich sage ist: ich finde keine Beispiel-Solutions, die ich downloaden und starten kann.
BeispielCodes vlt. zuhauf. Nur ist ein BeispielCode, rausgerissen aus seiner Solution nicht lauffähig.

Portabilität ist eine der Dimensionen des Vorteils von DatasetOnly: sowas kannste komplett zippen und zur Verfügung stellen, und jedermann, der mit VS arbeitet, kann das in 10 Sekunden starten, und im Debugger eingehend untersuchen.

ist nett, dass msdn schreibt, das Produkt sei Datenbank-unabhängig, aber in dem Sinne, dass es laufen täte, ganz ohne DB, trifft das schlicht nicht zu.
Das ist bestenfalls so zu verstehen, dass es nicht an einen bestimmten DB-Provider gebunden ist, also - Quälerei - wenn du Connectoren und Zeugs anderer Provider installierst - vlt. werden auch diese dann von EF unterstützt, zumindest teilweise.
Jdfs. bin ich mit meinen Versuchen, es mit SqlCe zu betreiben, gescheitert daran, dass die Primärschlüssel-Generierung neuer Datensätze Mist gebaut hat.

Eine andere Dimension ist, dass bei EF immer 2 Schichten Datenmodell zu pflegen und synchron zu halten sind: die Datenbank und der ObjectContext.
Bei DatasetOnly gibts nur eine Schicht, und um die zu pflegen, muss VisualStudio nichtmal verlassen werden.

ErfinderDesRades schrieb:

Eine andere Dimension ist, dass bei EF immer 2 Schichten Datenmodell zu pflegen und synchron zu halten sind: die Datenbank und der ObjectContext.
Bei DatasetOnly gibts nur eine Schicht, und um die zu pflegen, muss VisualStudio nichtmal verlassen werden.

Wie gesagt. Das Entity Framwork hat die Möglichkeit entweder dein Modell aus der Datenbank heraus zu generieren oder die Datenbank aus dem Modell. Ist also ein einzelner Klick um etwas zu aktualisieren.

ErfinderDesRades schrieb:

sowas kannste komplett zippen und zur Verfügung stellen, und jedermann, der mit VS arbeitet, kann das in 10 Sekunden starten, und im Debugger eingehend untersuchen.

Das mag schon stimmen. Jedoch ist das oftmals einfach nicht gefordert. Man packt nunmal keine Datenbanken in eine Visual Studio Solution und zippt diese. Trotzdem braucht man Datenbanken - zumindest je nach Anwendungsfall.
PS: Sehe nicht ein weshalb ich einen Artikel für vbp schreiben soll, wenn es schon hunderte bestehende Artikel auf codeproject, channel9,... gibt. Englisch sollte hier ja zumindest jeder halbwegs verstehen. Ach ja. Herunterladen ist das eine. Lesen ist das andere. Ich habe sogar schon bei Projekten im Anhang eine leere Textdatei hinaufgeladen mit Dateinamen "Aktueller Release befindet sich auf xyz.com". Selbst diese Datei hatte mehr als 30 downloads. Bei CSCore zum Beispiel ist auch schon seit nem Jahr der aktuelle Release auf codeplex. Drüber steht in großer Schrift "nicht herunterladen -> ist auf codeplex". Trotzdem habe ich jeden Tag downloads ;).

ja, dann verlink doch bitte auf diese Artikel, und bewahre GermanElectronix vor der sinnlosen Quälerei mit der veralteten Dataset-Technologie!

ansonsten wäre ein deutschsprachiger Artikel schon ein Segen für viele (mich eingeschlossen).

Erstmal vielen Dank für diese ausführlich Diskussion. Aber: Gibt es keine andere Möglichkeit als eine Datenbank? Mein Linux Server hat schon mehr als genug am Hals. Ich habe mich leider noch nicht mit MySQL in Verbindung mit VB befasst.

Nunja, Möglichkeiten gibt es da schon, via FTP Server XML Dateien hin und her schaufeln, oder auch mit normalen TXT Dateien, aber diese Methodik sollte man auf keinen Fall nutzen, ist meiner Meinung nach ziemlich schlampig.
Oder ggf. verwaltet ein TCP Server den du machst Anfragen (was im Endeffekt ein VB Anwendung wäre, die die Methodik von Erfinder des Rades einbaut, oder ähnliche), aber ist halt auch nicht das goldene vom Ei.

Ich bin mal ehrlich und sage, dass ich mich damals immer um Datenbanken gedrückt habe, mittlerweile bin ich sau froh, dass dies nicht mehr so ist ;)!

Wies auf Linux aussieht weiß ich leider nicht, habe mich damit noch nie damit befasst, weil Windows einfach mein "zu Hause" ist :), daher kann ich da nicht viel zu sagen.

Hättest du eventuell das ein oder andere Tutorial für Anfängerköpfe wie mich parat?

Für SQL Datenbanken meinst oder Ersteres/Schlechteres (:/)..?

Natürlich SQL.

Ne Frage noch:
- Möchtest du denn ne eigene MSSQL Server Instanz aufsetzen, oder besitzt du einen, oder wie ist das geplant?

Wenn du Marke Eigenbau wählrst, dann kannst du dir diese Video-Reihe hier anschauen.

Ich mache mir dann eine neue Datenbank auf meinem Server. Ich denke mal es macht keinen Unterschied ob das ganze über Windows oder Linux läuft.

Okay, die normale Variante Daten abzufragen wäre so / so hab ichs gelernt.. - Verbesserungsvorschläge natürlich gerne gesehen ;)!
Alternativ gibts dazu in den MySettings die Option, den Connection-String als Verbindungszeichenfolge zu speichern. MMn auch nicht so toll.. Weiß nicht ob das .NET Framework da irgendwas sicherer wurschtelt oder so.

Man sollte natürlich Passwörter etc. blabla nie in den Quelltext speichern..

GermanElectronix schrieb:

Ich denke mal es macht keinen Unterschied ob das ganze über Windows oder Linux läuft.

Musste halt schauen ob der SQL Server auf Linux läuft. Ist halt ein Microsoft Produkt von dem her würde ich nicht drauf schwören. Hab aber auch schon gehört, dass man da mit wine was zurecht zaubern kann.

Rootbob91 schrieb:

Verbesserungsvorschläge natürlich gerne gesehen ;)!

Solche Datenbankabfragen werden eigentlich nur äußerst selten verwendet. Zum einen musst du die SQL Abfragen als String schreiben, welcher zudem schwer wartbar ist und dazu ist das alles noch sau unübersichtlich.
Wie bereits zuvor diskutiert. Entweder Dataset oder Entity Framework:
Beispiel kann ich so ausm Kopf nur in C# schreiben -> musste mit nem Converter konvertieren lassen

Einfache Abfrage zum Vorname und Nachname auszugeben:


Dann eine Abfrage wo z.B. nur Personen ausgegeben werden die mindestens 12 Jahre alt sind:


Im Hintergrund geht dann halt z.B. so eine Abfrage an den Server: SELECT Vorname, Nachname FROM Personen WHERE Alter >= 12. Kannste mit z.B. Intellitrace nachschauen was an die Datenbank geht. Ist aber im Grund recht wurscht. Alles was du machst ist normalen C# oder VB.NET Code schreiben.