Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

11

09.11.2015, 22:51

Und was soll am Ende jetzt genau das Ziel mit diesen Daten sein? Du möchtest ein Produkt nach Titel auswählen und daraus dein Objekt erzeugen wobei Datenblätter und Review passend eingehangen werden? Das würde ich dann tatsächlich einfach per join lösen. Auch wenn dann ein paar Daten redundant sind, was ja nicht unbedingt schlimm ist.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

12

10.11.2015, 06:39

SQL ist nicht wie NoSQL oder OO-Datenbanken. Einen anderen Weg als Join sehe ich da ebenfalls nicht. Kommt dabei zu Redundanz, aber so läuft es bei SQL.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

buggypixels

Treue Seele

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

13

10.11.2015, 08:56

Deine Frage zeigt perfekt auf, warum ein Vergleich mongodb und "plain" SQL sinnfrei ist. Es sind zwei komplett unterschiedliche Ansätze und die kannst Du nicht sinnvoll vergleichen.
Etwas anderes wäre es, wenn Du auch auf SQL einen ORM Framework einsetzen würdest. Das wäre dann eher ein Vergleich. Also mongodb und zum Beispiel einen SQL Ansatz mit Hibernate.
Jeder, der sich mit SQL auskennt, wird sich sonst fragen was das soll und vor allem was Deine Erwartungshaltung hier ist.
Du mußt halt alle 3 Tabellen mit einander verbinden und SQL liefert dir dann eine Ergebnismenge mit allen Einträgen. Denn SQL macht genau das, was Du willst.

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

14

10.11.2015, 09:24

Jut, also habe ich nichts übersehen.
Es ging nur darum eine mögliche "schöne" Lösung nicht zu übersehen. Ich bleibe jetzt erstmal bei 3 Statements.

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

15

23.11.2015, 16:32

Hallo,

ich nutze das Thema hier einfach mal weiter.
Also ich hatte hier mal das Modell gezeigt, das evt. schon wieder etwas anders aussieht.
Und ich bin soweit mit meinen use cases durch. Jedoch fehlt noch einer für Transaktionen und konkurrierenden Zugriff.
Fällt euch irgendein Beispiel mit den Enitäten aus der Grafik ein wo man das zeigen könnte? Ich möchte einmal herausstellen, dass gleichzeitige Zugriffe auf mongodb evt. nicht konsistent sind und auf der anderen Seite Transaktionen verwenden (was an sich einfach ist, jedoch muss das Beispiel dies hergeben).
Evt. könnte man auch einen "Absturz" simulieren, aber da wüsste ich jetzt nicht wie für mongodb. Konkurrierende Zugriffe sollten über goroutines einfach sein. Aber auch da müsste ich schauen wie ich jetzt beweise das zwei Zugriffe "gleichzeitig" waren...
»DeKugelschieber« hat folgendes Bild angehängt:
  • Relationales_Modell.jpg

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

16

23.11.2015, 17:09

Das ist zwar keine Antwort auf deine Frage, aber ein paar Anmerkungen zu deinem letzten Schema (teilweise nur für reale Systeme wichtig):
  • Preise bzw. Geldbeträge im Allgemeinen niemals mit FLOAT darstellen! Für sowas gibt es DECIMAL.
  • Warum speicherst du die Summe der Produkte im Warenkorb eines Benutzers? Das macht doch nur Ärger, wenn du z. B. die Preise der Produkte anpasst.
  • Passwörter niemals im Klartext speichern, sondern nur einen sicheren Hash.
  • Ein Produkt sollte vielleicht auch mehreren Kategorien angehören können.
  • Was sollen die sort-Spalten bedeuten?

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

17

23.11.2015, 19:39

1. Ja das sollte ich noch ändern.
2. Die speichere ich nur exemplarisch um Operationen über große Datenmengen zu zeigen, natürlich wäre es sinnvoller den Preis einfach jedes mal zu berechnen.
3. Bespielanwendung
4. Bespielanwendung
5. sort sollte ich auch mal umbenennen. Ist für die Sortierung in der Anzeige.

Und naja, es ist halt ein Bespiel, daher simpel gehalten. Und dazu soll es noch nicht mal umfangreich werden (30 Seiten, bin bei 28 und kommen bestimmt noch 10?).

Für Transaktionen habe ich einfach einen bestehenden UC angepasst, wo das sogar noch sinnvoll war (weil mehr als ein Statement ausgeführt wurde, über den gesamten Prozess).
Aber konkurrierende Zugriffe wären noch cool...

Werbeanzeige