Datenbanken

[Simon Moon]

Hi

Ich plane gerade sowas wie ein kleine Schachliga und da brauch ich leider halt eine Datenbank im Hintergrund. Nun hab ich aber so praktisch keine Ahnung von Datenbanken. Also ok, ich weiss das relationale Datenbanken halt sowas wie ne grosse Exceltabelle ist und NoSQL Datenbanken gleich ganze Objekte abbilden koennen. Aber damit hat sichs dann auch schon praktisch.

Fuer mein Projekt dacht ich waere mariadb/mysql wohl ausreichend und dann gibts zwei DBs: die eine fuer Spieler, die andere fuer Spiele, die etwa nachfolgende Daten speichern (mal ganz rudimentaer, simpel):

Spieler
ID, Name, ELO

Spiele
ID, Datum, Weiss Spieler-ID, Schwarz Spieler-ID, Sieg/Niederlag/Unentschieden

Nun verstehe ich das richtig, dass ich im Prinzip den ELO Algroithmus direkt in SQL formulieren kann und wenn dann ein neues Spiel in die Datenbank eingegeben wird, sucht sich die DB anhand der Spieler-ID die ELO von Spieler Weiss und Schwarz und verechnet diese mteinander, je nachdem was beim Spiel unter Sieg/Niederlage/Unenetschieden angegeben wird? Oder geht diese Logik doch in den Programmcode der App und die DB haelt effektiv nur die Daten vor?

Gibt es irgendwelche Tipps und Tricks die ihr empfehlen koenntet oder Stolperfallen in die Anfaenger gerne treten? Miy einer MySQL/MariaDB mach ich da denke ich auch nichts falsch und kann da erstmal rumwerkeln ohne gleich an Grenzen zu stossen? Hab irgendwie halt keinen Bock mich jetzt im Vorfeld tief mit Datenbanken zu beschaeftigen - zuerst soll da halt einfach eine klein App sein, mit Rangliste und Spielhistorie. Spaeter sollen dann Member selber Spiele eintragen koennen, aber die sollen dann natuerlich nicht direkt auf die DB Zugriff haben sondern ueber eine Api an Nginx Unit / irgendne Cloud / weiss noch nicht ihre Spielergebnisse senden.

LG SM

[Monger]

Wer mit Datenbanken groß geworden ist sieht das bestimmt anders, aber nicht umsonst ist NoSQL so beliebt...
Optimier gar nix. Rotz alles rein, halte die ganze Logik in deiner App. Optimiere mit besseren Queries, Verknüpfungen etc. sobald du es brauchst, aber keine Minute früher.

[Simon Moon]

Wer mit Datenbanken groß geworden ist sieht das bestimmt anders, aber nicht umsonst ist NoSQL so beliebt...


Mir ist im Prinzip so ziemlich egal was da fuer eine DB im Hintergrund laeuft. Es soll nur so einfach wie moeglich von Python ansprechbar sein. Performance ist denke ich kein wichtiges Kriterium - allenfalls werden da mal so ein paar tausend Spiele und eine zwei bis dreistellige Zahl an Spielern vorhanden sein.

Kann ich denn da fuer den Aufbau einer Spieler-Datenbank eine NoSQL DB wie MongoDB gleich behandeln wie mysql? Im Prinzip sollte die Handhabung denke ich kaum schwieriger sein, da die DB ja von Haus aus mit JSON arbeitet (wenn ich mich richtig erinnere), das Ding ist eher, dass ich zumindest "glaube" das Konzept von relationalen Datenbanken etwas zu verstehen, waehrend NoSQL bei mir nur ein Fragezeichen ausloest. Aber eigentlich ist mir auch ziemlich egal wie die DB funktioniert - meinetwegen koennte das auch ein csv file oder ein smb share mit gezipten txt-files sein.

Ich glaub ja sowieso, dass Datenbank-Programmierer auch Leute aus der Buchhaltung daten und dann gemeinsam unbedruckte Puzzle zusammensetzen.

Optimier gar nix. Rotz alles rein, halte die ganze Logik in deiner App. Optimiere mit besseren Queries, Verknüpfungen etc. sobald du es brauchst, aber keine Minute früher.

Hm, ueber Queries hab ich mir jetzt tatsaechlich noch gar keine Gedanken gemacht. In meiner naiven Vorstellung gings noch nicht weiter als "DB gib mir ID xy" und dann erhalte ich ein Objekt zurueck. Oder eben "DB fuege neues Spiel hinzu Weiss-id:111 Schwarz-id:222 Resultat:1". Am meisten besorgt mich halt, dass sich strukturell etwas falsch angeh und das dann spaeter nicht mehr einfach anpassen kann.

[Marscel]

Am meisten besorgt mich halt, dass sich strukturell etwas falsch angeh und das dann spaeter nicht mehr einfach anpassen kann.

Die größte Hilfe ist mEn, sich wirklich mal kurz zu überlegen, was man alles haben will bzw. unbedingt braucht: Anforderungen halt. Schreib es dir auf, mal es auf, was auch immer. Nichts ist Frustrienender als Herumzunudeln und am Ende festzustellten, dass man fahrlässig Käse gebaut hat. (*)

Daraus ergibt sich dann, was besser oder schlechter geeignet ist. Kommst du mit einem Haufen Daten unter einigen Keys aus? Versuchs mit NoSQL. Brauchst du Transaktionssicherheit, schematische und referentielle Integrität, spezielle Indexierungen und Joins? Was Relationales.

(*) Es gibt auch Leute, die genau das tun, Prototypenentwicklung, das macht aber nur dann besonders Sinn, wenn Nutzer noch keine allzu konkrete Peilung haben, was sie wie am besten brauchen, auf die Gefahr hin, einfach nochmal alles wegwerfen zu müssen, entsprechend unbemüht mag dann auch das Resultat intern sein. Das seh ich hier aber nicht.

[Simon Moon]

Soweit ich das aktuell sehe, sind da eigentlich nur zwei Objekte: Spiele und Spieler. Als JSON wuerd ich die etwa so darstellen:

{
"Spieler":{
"uuid": "9a1b37d8-0a1d-4f65-a642-0629445a54fb",
"name": "Simon Moon",
"email": "moon@3dc.org",
"elo": 9001,
"gespielt":{
"heute": 7,
"jahr": 24,
"gesamt": 233
},
},
"Spiel":{
"uuid": "72d78afb-8ddd-48f3-9b5b-51169ade3477",
"weiss-uuid": "9a1b37d8-0a1d-4f65-a642-0629445a54fb",
"schwarz-uuid": "3a59b424-a8b3-4879-82dd-b1bd3e30c283",
"resultat": 1,
"datum": "2022-6-14",
"ort": "3dc-Kaserne",
"format": "bullet",
"notiert" : true,
"moves": ["e4", "e5", "Nf3", "Nc6", "Bb5", "a6", "Ba4", "Nf6", "O-O", "Be7", "Re1", "b5", "Bb3", "d6", "c3", "O-O", "h3", "Nb8", "d4", "Nbd7", "c4", "c6", "cxb5", "axb5", "Nc3", "Bb7", "Bg5", "b4", "Nb1", "h6", "Bh4", "c5", "dxe5", "Nxe4", "Bxe7", "Qxe7", "exd6", "Qf6", "Nbd2", "Nxd6", "Nc4", "Nxc4", "Bxc4", "Nb6", "Ne5", "Rae8", "Bxf7+", "Rxf7", "Nxf7", "Rxe1+", "Qxe1", "Kxf7", "Qe3", "Qg5", "Qxg5", "hxg5", "b3", "Ke6", "a3", "Kd6", "axb4", "cxb4", "Ra5", "Nd5", "f3", "Bc8", "Kf2", "Bf5", "Ra7", "g6", "Ra6+", "Kc5", "Ke1", "Nf4", "g3", "Nxh3", "Kd2", "Kb5", "Rd6", "Kc5", "Ra6", "Nf2", "g4", "Bd3", "Re6"]
},
}

Die DB muesste nun:
- Nach der Elo-Zahl sortieren
- Anzahl Spiele von Spieler ab in Zeitraum xy zurueckgeben. Wobei da kann ich auch einfach einen counter einbauen, statt jedes mal zu berechnen.
- spaeter wohl die Objekte erweitern koennen.
- die Elo-Historie irgendwie wiedergeben koennen und evtl. neu berechnen - sollte ich dafuer die aktuelle elo-zahl evtl. im Spiel auch festhalten?

Ansonsten versuch ichs fuer den Anfang halt moeglichst simpel halten.

[medi]

Nimm ne relationale DB und bau dir 3 Tabellen: Spieler, Spiele und Match
Das sollte reichen.
In Spieler kommen die Spieler.
In Spiele kommen die Spiele.
Und in Match verknüpfst du die jeweiligen Spieler mit dem jeweiligen Spiel.
Als index nimmst du die Spieler_ID sowie die Spiel_ID, sowie die Match_ID

Dann kannst du dir mittels JOINs alle benötigten Daten pro Query rausholen.

Als Datum würde ich nen timestamp nutzen. Das ist glaub ich einfacher bei Berechnungen.
Einen counter würde ich nicht speichern sondern lieber jedes mal berechnen. Mit nem timestamp als Datum ist das easy.
Die ELOs pro match kannst du in die Spiel Tabelle packen. Da gehört die imo hin.

[Grendizer]

Den Namen in Vorname und Nachname aufteilen. Wer weiss., für was man die Daten in Zukunft noch verwenden will.

[Simon Moon]

@medi
Ich generier ja sowieso fuer jedes Spiel eine neue ID, dann hab ich ja am Ende einfach eine Match_ID und eine Spiel_ID welche auf die gleiche Begegnung verweisen? Ist das einfach eine Massnahme um Struktur und Uebersichtlichkeit zu wahren und in Match koennt ich dann z.b. noch Location_ID reintun, wenn ich jetzt noch ein weiteres Objekt "Ort" haette?

Den Namen in Vorname und Nachname aufteilen. Wer weiss., für was man die Daten in Zukunft noch verwenden will.

Solche Daten will ich erst gar nicht. Kommerzielle Absichten hab ich bei dem Projekt sowieso keine und das Risiko, dass die Daten in falsche Haende geraten ist mir da zu gross. Sei das durch Fehlkonfiguration, eine Sicherheitsluecke oder staatliche Stellen die Begehrlichkeiten entwickeln und das dann gerichtlich erzwingen wollen.

[medi]

@medi
Ich generier ja sowieso fuer jedes Spiel eine neue ID, dann hab ich ja am Ende einfach eine Match_ID und eine Spiel_ID welche auf die gleiche Begegnung verweisen? Ist das einfach eine Massnahme um Struktur und Uebersichtlichkeit zu wahren und in Match koennt ich dann z.b. noch Location_ID reintun, wenn ich jetzt noch ein weiteres Objekt "Ort" haette?

Location_ID würde ich auch ans Spiel hängen. Macht die Queries einfacher.
Das verlangt allerdings noch nach ner weiteren Tabelle "Location" wo du die Location_ID und den Namen (+ whatever) der Location fest hälst.

Die Match Tabelle würde auch nicht zwingend benötigt. Du kannst die Daten auch in der "Spiel" Tabelle halten da bei einem Match ja eigentlich immer fix 2 Spieler teilnehmen. Somit könntest du in die "Spiel"-Tabelle auch einfach 2 Einträge hinzufügen: Spieler1_ID und Spieler2_ID. Nicht schön aber in diesem Fall wohl akzeptabel.
Ist halt alles ne Frage der Normalisierung. Die kann man weit treiben, man kanns aber auch sein lassen. Auf jeden Fall Redundanzen vermeiden. Deswegen Spieler und Location in Extra Tabellen auslagern, damit die Namen nicht mehrfach in der "Spiel" Tabelle auftauchen und du die Spieler/Locations ggf. auch später auch um weitere Eintragungen erweitern kannst.
Das Format würde ich übrigens auch in ne "Format" Tabelle auslagern und über ne Format_ID in die "Spiel" Tabelle einbinden.

Moves musst du wohl auch auslagern. Ich wüsste sonst nicht wie man das in ne MySQL Tabelle reinbekommt.

Edit: https://sebhastian.com/mysql-array/
Hat auch irgendwo Charm. Auswerten müsste man das dann aber wohl mit Phyton.

[Exxtreme]

Ich würde es auch mit einer relationalen Datenbank machen. Die sind gut abgestanden und gutes Tooling ala ORMs gibt es auch.


Und was das Design angeht, eine m:n-Verknüpfung zwischen Spieler und Spiele.

[#44]

Für ein kleines Hobbyprojekt ist vmtl. eh alles recht egal. Solange du keinen DB Typ wählst und an jeder Ecke das genaue Gegenteil von dem tust, wie man eine DB optimal verwendet, dürfte Performance kein Problem werden.

Als beginner würde ich davon Abstand nehmen, Logik in SQL/Triggern/etc. zu Implementieren. Theoretisch könnte eine SQL-DB die Logik komplett abbilden. Ist aber Lernaufwand und birgt stolperfallen. Mischmasch ist hier auch nicht ratsam - macht nur das Debugging schwer.


- Anzahl Spiele von Spieler ab in Zeitraum xy zurueckgeben. Wobei da kann ich auch einfach einen counter einbauen, statt jedes mal zu berechnen.
Das halte ich für einen Fehler. Datenbanken sind unglaublich gut darin, Auskunft über ihre Daten zu geben. Anzahlen zu bestimmen gehört da dazu.
Du willst dich nicht mit Problemen mit der Konsistenz deiner Zählungen herumschlagen.

Entsprechend würde ich auch die Game Counter ("gespielt") nicht speichern.

- die Elo-Historie irgendwie wiedergeben koennen und evtl. neu berechnen - sollte ich dafuer die aktuelle elo-zahl evtl. im Spiel auch festhalten?
Ich halte es für sinnvoll, die mit zu speichern. Neu berechnen sollte nicht nötig sein.


Ich bin außerdem der Meinung, "Resultat" sollte kein int sein. (Falls ich dessen Bedeutung jetzt nicht falsch interpretiere) Mach dir ein aussagekräftiges Enum und Speicher die Werte als String.

Ansonsten halte ich deinen Entwurf für die Struktur für gut.

[chetigol]

Mir ist im Prinzip so ziemlich egal was da fuer eine DB im Hintergrund laeuft.

Und genau so solltest du auch deine Applikation Entwickeln! Nicht mit Hinblick auf die zugrundeliegende Technologie (Datenbanken usw) sondern den Fokus auf die Domäne legen!

Die Datenbank solltest du über eine Infrastruktur-Schicht - zum Beispiel mit Hilfe von Repositories - abstrahieren. Die Repositories liefern dir die benötigten Entities,..

So könntest du im ersten Wurf nur eine einfach In-Memory Datenbank einsetzen. In einfachen Maps die Daten ablegen. Und später dich dann für eine Datenbank entscheiden.

[Asaraki]

Wer mit Datenbanken groß geworden ist sieht das bestimmt anders, aber nicht umsonst ist NoSQL so beliebt...
Optimier gar nix. Rotz alles rein, halte die ganze Logik in deiner App. Optimiere mit besseren Queries, Verknüpfungen etc. sobald du es brauchst, aber keine Minute früher.

Nä, NoSQL ist doch nice und das sage ich als Ex-DBA für RDBMS :)

Hat alles seinen Nutzen und die Wahl des Systems ist (von sehr grossen Firmen mal abgesehen) weniger wichtig als die Qualität und vor allem KONSISTENZ des Designs.

Stay true to your own rules.

Ich empfehle einfach seine DB zumindest in den Basics zu verstehen. Also möglichst keine Frameworks nutzen sonst hast du den ganzen Spass wie in Django und keine Ahnung warum deine DB so aussieht wie sie aussieht.


Daher : Wenn du was nicht verstehst, nochmal anschauen und im Zweifelsfall fragen. Dann hast du danach auch was für die Ewigkeit.

[lumines]

Gibt es irgendwelche Tipps und Tricks die ihr empfehlen koenntet oder Stolperfallen in die Anfaenger gerne treten? Miy einer MySQL/MariaDB mach ich da denke ich auch nichts falsch und kann da erstmal rumwerkeln ohne gleich an Grenzen zu stossen? Hab irgendwie halt keinen Bock mich jetzt im Vorfeld tief mit Datenbanken zu beschaeftigen - zuerst soll da halt einfach eine klein App sein, mit Rangliste und Spielhistorie. Spaeter sollen dann Member selber Spiele eintragen koennen, aber die sollen dann natuerlich nicht direkt auf die DB Zugriff haben sondern ueber eine Api an Nginx Unit / irgendne Cloud / weiss noch nicht ihre Spielergebnisse senden.

Guck dir einmal SQLAlchemy an. Das ist so das Standard-ORM für Python. Ein ORM mappt letztendlich Objekte auf ein relationales Schema, entsprechend ist dein Datenbankschema einfach in entsprechenden Klassen definiert. SQLAlchemy unterstützt haufenweise Datenbanken, von daher wirst du sehr wahrscheinlich niemals etwas anderes einsetzen müssen. Wenn du einmal dein Datenbankschema mit deinem ORM definiert hast, kannst du jederzeit auch zu MySQL oder PostgreSQL switchen.

Dein Datenbankschema kannst du relativ schnell per SQLAlchemy und SQLite erstellen und ein bisschen rumprobieren. SQLite basiert nicht auf einem Client-Server-Modell, daher ist deine Datenbank einfach eine Datei in deinem Dateisystem. Python hat SQLite-Support schon in der Standardlibrary drin (allerdings ohne ein ORM), daher brauchst du eigentlich nur SQLAlchemy als Library und kannst ohne weiteres Setup einer Entwicklungsumgebung direkt anfangen.

Wenn du das Quick-Start-Tutorial einmal überfliegst, sollte das zum Erstellen eines relativ simplen Datenbankschemas eigentlich auch schon ausreichen, auch wenn man nicht so tief in SQL drinsteckt: https://docs.sqlalchemy.org/en/14/orm/quickstart.html

Als Webframework kannst du dann Flask oder FastAPI nutzen, welche beide auch bevorzugt SQLAlchemy benutzen.

Und ein kleiner Tipp: Viele relationale Datenbanken können mittlerweile zusätzlich strukturierte Daten oder direkt JSON speichern und bieten dafür dann ein paar Convenience-Funktionen an. Wenn du also Daten hast, die du so gar nicht in ein relationales Schema abbilden kannst oder willst, kann das natürlich immer noch eine komfortable Alternative sein ohne direkt komplett auf eine NoSQL-Datenbank switchen zu müssen.

Ich empfehle einfach seine DB zumindest in den Basics zu verstehen. Also möglichst keine Frameworks nutzen sonst hast du den ganzen Spass wie in Django und keine Ahnung warum deine DB so aussieht wie sie aussieht.

Solche Frameworks wie Django sind schon sehr sinnvoll, wenn man eine relativ standardisierte CRUD-Anwendung aufziehen will. Diese Frameworks sind nicht ohne Grund relativ "opinionated", im Grunde sind das auch nur die Konventionen ähnlicher Projekte in Code gegossen.

Ich würde es eher so sehen: Wer direkt zu NoSQL greift, will häufig einfach nur die Convenience von NoSQL-Datenbanken, aber eigentlich relativ selten ein NoSQL-Datenmodell. Die Flexibilität von NoSQL-Datenbanken geht relativ schnell flöten, weil man viel zu viele Funktionen relationaler Datenbanken irgendwann in der Applikation nachbauen muss, was die ganze Sache relativ witzlos macht.

[Exxtreme]

Dein Datenbankschema kannst du relativ schnell per SQLAlchemy und SQLite erstellen und ein bisschen rumprobieren.

Wobei ich das nicht tun würde. :) Wenn man ORMs das DB-Schema generieren lässt dann kann da echt merkwürdiges Zeug rauskommen, welches langsam ist weil es unnatürlich für relationale Datenbanken ist. Sprich, es ist besser es andersrum zu machen, IMHO. Also man erstellt das Schema in der Datenbank und passt dann die ORM-Entities an dieses Schema an. Dann wird es eventuell unnatürlich in der Programmierung aber die Performance bleibt.

[lumines]

Wobei ich das nicht tun würde. :) Wenn man ORMs das DB-Schema generieren lässt dann kann da echt merkwürdiges Zeug rauskommen, welches langsam ist weil es unnatürlich für relationale Datenbanken ist. Sprich, es ist besser es andersrum zu machen, IMHO. Also man erstellt das Schema in der Datenbank und passt dann die ORM-Entities an dieses Schema an. Dann wird es eventuell unnatürlich in der Programmierung aber die Performance bleibt.

Für Hobbyprojekte wird das eine eher untergeordnete Rolle spielen. Auch Python ist um ein Vielfaches langsamer als z.B. Java oder Go, aber am Ende spielt auch das in vielen Fällen einfach keine Rolle.

Man kann SQLAlchemy allerdings auch als reinen Query Builder ohne ORM nutzen: https://docs.sqlalchemy.org/en/14/core/

Das ist wahrscheinlich auch einer der Gründe, warum SQLAlchemy bei Python so beliebt ist. So eine Flexibilität haben andere ORMs häufig nicht und man muss dort immer irgendeinen Kompromiss eingehen.

[FeuerHoden]

Soweit ich das aktuell sehe, sind da eigentlich nur zwei Objekte: Spiele und Spieler. Als JSON wuerd ich die etwa so darstellen:

{
"Spieler":{
"uuid": "9a1b37d8-0a1d-4f65-a642-0629445a54fb",
"name": "Simon Moon",
"email": "moon@3dc.org",
"elo": 9001,
"gespielt":{
"heute": 7,
"jahr": 24,
"gesamt": 233
},
},
"Spiel":{
"uuid": "72d78afb-8ddd-48f3-9b5b-51169ade3477",
"weiss-uuid": "9a1b37d8-0a1d-4f65-a642-0629445a54fb",
"schwarz-uuid": "3a59b424-a8b3-4879-82dd-b1bd3e30c283",
"resultat": 1,
"datum": "2022-6-14",
"ort": "3dc-Kaserne",
"format": "bullet",
"notiert" : true,
"moves": ["e4", "e5", "Nf3", "Nc6", "Bb5", "a6", "Ba4", "Nf6", "O-O", "Be7", "Re1", "b5", "Bb3", "d6", "c3", "O-O", "h3", "Nb8", "d4", "Nbd7", "c4", "c6", "cxb5", "axb5", "Nc3", "Bb7", "Bg5", "b4", "Nb1", "h6", "Bh4", "c5", "dxe5", "Nxe4", "Bxe7", "Qxe7", "exd6", "Qf6", "Nbd2", "Nxd6", "Nc4", "Nxc4", "Bxc4", "Nb6", "Ne5", "Rae8", "Bxf7+", "Rxf7", "Nxf7", "Rxe1+", "Qxe1", "Kxf7", "Qe3", "Qg5", "Qxg5", "hxg5", "b3", "Ke6", "a3", "Kd6", "axb4", "cxb4", "Ra5", "Nd5", "f3", "Bc8", "Kf2", "Bf5", "Ra7", "g6", "Ra6+", "Kc5", "Ke1", "Nf4", "g3", "Nxh3", "Kd2", "Kb5", "Rd6", "Kc5", "Ra6", "Nf2", "g4", "Bd3", "Re6"]
},
}

Die DB muesste nun:
- Nach der Elo-Zahl sortieren
- Anzahl Spiele von Spieler ab in Zeitraum xy zurueckgeben. Wobei da kann ich auch einfach einen counter einbauen, statt jedes mal zu berechnen.
- spaeter wohl die Objekte erweitern koennen.
- die Elo-Historie irgendwie wiedergeben koennen und evtl. neu berechnen - sollte ich dafuer die aktuelle elo-zahl evtl. im Spiel auch festhalten?

Ansonsten versuch ichs fuer den Anfang halt moeglichst simpel halten.

Wurde schon erwähnt, Vorname, Nachname getrennt. Wie willst mit doppelten Vor- und Nachnamen umgehen? Sind irgendwelche (Adels)Titel zu beachten?
Anzahl Spiele: Beide Methoden verwenden und Resultate vergleichen um mögliche Abfragefehler schneller zu bemerken
ELO Historie: Ebenfalls beide Varianten parallel als Gegenprobe.
So würde ich auch die Summen der gespielten Spiele vergleichen
Willst du die Zeit pro Zug ebenfalls festhalten? Willst du festhalten ob eine Niederlage durch Aufgeben oder Zeitmangel entschieden wurde?


Allgemein würde ich sagen dass eine Schach-DB schon erfreulich schlank ist, da schadet etwas Overhead wenig. Ich würde somit soetwas wie die ELO Historie eher ablegen als jedes Mal neu berechnen.

[Simon Moon]

Ich hab mich jetzt mal fuer eine MongoDB entschieden. Und der Plan sind nun jeweils fuer Player, Game & Location je eine Collection anzulegen. Das wirkt mir irgendwie simpler, als mir da grossartig ueber die Struktur gedanken zu machen und die pymongo ist simpel zu bedienen. Mongo Compass scheint mir auch ein verstaendliches GUI Tool zu sein.

Dazu mal ein kleines cli-script hingehackt, mit dem ich Spieler eintragen kann und eines, dass spiele eintraegt und die Elo-Zahl beim Spieler updatet. Da ist jetzt sicher noch unnoetige Redundanz bei, andererseits finde ich z.b. das Datum seperat zu speichern durchaus sinnvoll, da der Eintrag ja nicht unbedingt dann geschieht, wenn die Partie gespielt wurde.

Spiele sehen so aus:
{
"_id": {
"$oid": "62ad9b2610ccf80ff4f0d850"
},
"Datum": {
"$date": "2022-06-18T09:30:14.106Z"
},
"Timestamp": 1655537414.106205,
"uuid-location": "yada",
"uuid": {
"$binary": "wRZNiyooTke4SeOwlflUOw==",
"$type": "4"
},
"uuid-white": {
"$binary": "w+QzwGn6Ts6KUEMwaa24cA==",
"$type": "4"
},
"elo-white_before": 1005.9856088829084,
"elo-white_after": 1000.8994775679156,
"uuid-black": {
"$binary": "BBhgmegQSamDlh3R2hG2Ag==",
"$type": "4"
},
"elo-black_before": 1000,
"elo-black_after": 1005.0861313149928,
"result": "b"
}


Spieler so:
{
"_id": {
"$oid": "62a9dc5976a2ba657b2cd880"
},
"uuid": {
"$binary": "yZ9Kh0KoT9aPaRrobtmOxw==",
"$type": "4"
},
"Registriert": {
"$date": "2022-06-15T13:19:21.062Z"
},
"Timestamp": 1655291961.062473,
"Name": "hansruedi",
"Email": "hansruedi@schach.com",
"Location": "haifischbar",
"Elo": 995.0143911170916
}



Aber das naechste Ziel ist jetzt denke ich mal, einen Application Server aufsetzen - da dachte ich an Nginx Unit und dann mal schauen, wie ich da eine API zusammenfrickel. Da wollte ich mich an OpenAPI orientieren. Natuerlch setz ich dann noch einen Reverse Proxy davor, bevor das ans Internet geht.

Ziel ist dann, dass sich ein Spieler einloggen kann bzw. da er auf seinem Smartphone sowieso eingeloggt ist, klickt er nur noch sowas wie Neues Spiel erstellen, waehlt welche Farbe er hatte, wo gespielt wurde und ob er gewonnen hat. Das generiert dann einen QRcode, den Spieler zwei nur noch einscannen und bestaetigen braucht. Die Anforderung ist, dass es auch nach 2 - 3 Litern Bier nicht zu kompliziert ist. Notation usw. bleibt auf jedenfall optional, genauso will ich auch keine persoenlichen Daten.

[Exxtreme]

Ich hab mich jetzt mal fuer eine MongoDB entschieden.

Bitte diese Lizenz beachten:
https://de.wikibrief.org/wiki/Server_Side_Public_License

https://www.mongodb.com/licensing/server-side-public-license

Kann sein, dass du den Sourcecode deines Programm unter die SSPL stellen und ihn veröffentlichen musst.

[Marscel]

Bitte diese Lizenz beachten:
https://de.wikibrief.org/wiki/Server_Side_Public_License

https://www.mongodb.com/licensing/server-side-public-license

Kann sein, dass du den Sourcecode deines Programm unter die SSPL stellen und ihn veröffentlichen musst.

Unwahrscheinlich, weil das eine Fuck-AWS-Klausel ist. Heißt, wenn du MongoDB als Dienst per direkter Interkation für Dritte anbietest, so als ob er MongoDB selbst nutzen würde, dann trifft das zu.

Wenn du das lokal auf einem Host laufen lässt, und nur dein Interface-Dienst zwischen User-Requests und Queries dispatcht, ist das Ok.

[lumines]

Wenn du das lokal auf einem Host laufen lässt, und nur dein Interface-Dienst zwischen User-Requests und Queries dispatcht, ist das Ok.

Dann legst du die Lizenz aber sehr "freundlich" aus. So direkt steht das dort nämlich nicht drin.

[Simon Moon]

Ja gut, das Projekt oeffentlich auf Github zu stellen, ist jetzt nicht das Problem. Die Frage ist bei mir jetzt eher, hat das eine Bedeutung fuer die Software die ich sonst noch verwende?

[Exxtreme]

Ja gut, das Projekt oeffentlich auf Github zu stellen, ist jetzt nicht das Problem. Die Frage ist bei mir jetzt eher, hat das eine Bedeutung fuer die Software die ich sonst noch verwende?
Verwendest du irgendwelche Skripte für die Datenbank ala Backup-Skripte? Wenn ja dann muss das auch unter die SSPL. X-D

Deshalb ist MongoDB auch aus sämtlichen Linux-Distributionen rausgeflogen weil die Linux-Distribution selbst unter die SSPL müsste.

[Simon Moon]

Verwendest du irgendwelche Skripte für die Datenbank ala Backup-Skripte? Wenn ja dann muss das auch unter die SSPL. X-D

Deshalb ist MongoDB auch aus sämtlichen Linux-Distributionen rausgeflogen weil die Linux-Distribution selbst unter die SSPL müsste.

Hm, dann also auch das systemd service file? :freak:

Und wie siehts dann z.b. mit systemd an sich aus.. oder nginx ... mir ists ja wirklich egal, wenn jemand was mit meinem Spaghetti-Code anfangen kann, wuerds mich ja ebenso freuen, wie wundern. Aber wo sind denn da die grenzen gezogen?

Ach man, die Software waer so simpel.

[Marscel]

Dann legst du die Lizenz aber sehr "freundlich" aus. So direkt steht das dort nämlich nicht drin.

Doch, eigentlich schon:

MongoDB unterliegt dieser Lizenz, dass man nicht nur bei Verteilung von MongoDB (als Binary) den Quellcode mit anbieten muss (wie bei der GPL), sondern hier auch mit dem Zusatz, dass ein Nutzer über das Netzwerk-Interface ein Anrecht auf den Code hat (wie bei der AGPL), und hier nochmal mit dem Zusatz, dass alles an Zusatztools zum Dienstbetrieb dessen durch Dritte (z. B die AWS UI um einen MongoDB-Service) auch darunterfällt.

Wenn ich nun was eigenes baue, das MongoDB allenfalls proxied, sodass ich praktisch nach wie vor einen Dienst abiete, der primär die Nutzung von MongoDB ermöglicht, dann wird die Lizenzverpflichtung zum Code-Release mit Sicherheit greifen.

SM baut jetzt, wenn ich das richtig verstanden habe, nichts was 1. MongoDB als Dienst für Dritte exponiert, sondern etwas eigenes dazwischen, das exklusiv damit interagiert (= das/er ist der Nutzer) und 2. nichts äquivalentes zu einem MongoDB-Service auf der Basis von MongoDB ... sondern Schach.

If you make the functionality of the Program [= MongoDB] or a modified version available to third parties as a service, you must [... Code publishen]. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

Wenn du als DB hintenherum MongoDB gegen MySQL, HBase oder so weiter austauschen könntest, ohne dass sich der Programmzweck/-wert, Schach, ändert, sind wir hier sicher.

[The_Invisible]

Habe ich auch immer so verstanden das es nur zutrifft wenn man MongoDB direkt als Service anbietet was man als normale Anwendung ja nie macht: https://www.mongodb.com/licensing/server-side-public-license/faq

[Exxtreme]

Hm, dann also auch das systemd service file? :freak:

Und wie siehts dann z.b. mit systemd an sich aus.. oder nginx ... mir ists ja wirklich egal, wenn jemand was mit meinem Spaghetti-Code anfangen kann, wuerds mich ja ebenso freuen, wie wundern. Aber wo sind denn da die grenzen gezogen?

Ach man, die Software waer so simpel.

Alles, was du zum Verwalten und Betrieb von MongoDB brauchst, muss unter die SSPL. Auch deine eigenen Skripte zum Backup, Starten/Stoppen der Datenbank etc. Das ist eine "Fuck you Amazon"-Lizenz damit die Cloud-Anbieter die kommerzielle Version lizenzieren. Die AGPL, unter der MongoDB vorher lizenziert war erzwingt solche Dinge nicht. Und wie geschrieben, Teile von Linux wären auch betroffen gewesen. Und da haben die Distributoren kurzen Prozess gemacht.

Wenn du dich mit sowas nicht abgeben willst, dann eine andere Datenbank mit anderer Lizenz wählen.

[lumines]

Doch, eigentlich schon:

MongoDB unterliegt dieser Lizenz, dass man nicht nur bei Verteilung von MongoDB (als Binary) den Quellcode mit anbieten muss (wie bei der GPL), sondern hier auch mit dem Zusatz, dass ein Nutzer über das Netzwerk-Interface ein Anrecht auf den Code hat (wie bei der AGPL), und hier nochmal mit dem Zusatz, dass alles an Zusatztools zum Dienstbetrieb dessen durch Dritte (z. B die AWS UI um einen MongoDB-Service) auch darunterfällt.

Wenn ich nun was eigenes baue, das MongoDB allenfalls proxied, sodass ich praktisch nach wie vor einen Dienst abiete, der primär die Nutzung von MongoDB ermöglicht, dann wird die Lizenzverpflichtung zum Code-Release mit Sicherheit greifen.

Das verstehst du darunter. Faktisch ist die SSPL aber eine "selbstgepatchte" AGPL ohne weiteren Input anderer Organisationen wie der OSI.

[Exxtreme]

Das verstehst du darunter. Faktisch ist die SSPL aber eine "selbstgepatchte" AGPL ohne weiteren Input anderer Organisationen wie der OSI.
Also den Input der OSI gab es hinterher schon. ;)

https://opensource.org/node/1099

[Marscel]

Das verstehst du darunter. Faktisch ist die SSPL aber eine "selbstgepatchte" AGPL ohne weiteren Input anderer Organisationen wie der OSI.

Ja, das versteh ich drunter, weil ich damals mal damit zu tun hatte: Hintergrund war, dass AWS & Co versch. OS-Software genommen haben, da einen managed Service drum gebaut haben, den Nutzer als Drop-In-Replacement für ihre Anwendungen 1:1 einsetzen können/konnten: Änder deine MySQL/Redis/ElasticSearch/MongoDB-Host/URL zu etwas in AWS, sonst nichts. Und natürlich Geld damit verdient hat.

Den Leuten von MongoDB passte das nicht, und selbst die AGPL von einst war für die unzureichend in der Hinsicht, dass AWS nun so einfach Gewinn damit macht, weil AWS ja nichts falsch machte, und damit fein raus war, den Source, den sie selbst kompiliert haben, anzugeben. Also wollten sie auch alles, was die darum an Tooling aufgebaut haben, kriegen, zumindest im Falle vom Einsatz von neueren Versionen, wo dann die SSPL stattdessen steht.

Mir fallen einige Dienste/Ideen ein, die davon ganz bestimmt betroffen sind/wären, sowas wie: Nutzer erwartet/hängt davon ab/kriegt eine Erweiterung/Tool zu der spez. SSPL-Software: Verwalte deine Daten bei uns wie mit X, aber bei uns kriegst du exkl. noch ein SQL-Interface drüber. Und Schach tut es ziemlich sicher nicht, genau wie es bei uns damals ein paar aggregierte Nutzerdaten-Dumps als eine Art Cache für ein Web-Frontend nicht taten.

Die Legals vom Investor hatten z. B. ihre Probleme mit der alten React-Lizenz, aber nicht mit MongoDB.

[lumines]

Ja, das versteh ich drunter, weil ich damals mal damit zu tun hatte [...]

Ich auch. Bei uns gab es viele Fragezeichen und man ist zum Schluss gekommen, dass man das Risiko nicht eingehen will.

[littlejam]

Wer mit Datenbanken groß geworden ist sieht das bestimmt anders, aber nicht umsonst ist NoSQL so beliebt...
Optimier gar nix. Rotz alles rein, halte die ganze Logik in deiner App. Optimiere mit besseren Queries, Verknüpfungen etc. sobald du es brauchst, aber keine Minute früher.
Nimm ne relationale DB und bau dir 3 Tabellen: Spieler, Spiele und Match
Das sollte reichen.
In Spieler kommen die Spieler.
In Spiele kommen die Spiele.
Und in Match verknüpfst du die jeweiligen Spieler mit dem jeweiligen Spiel.
Als index nimmst du die Spieler_ID sowie die Spiel_ID, sowie die Match_ID

Dann kannst du dir mittels JOINs alle benötigten Daten pro Query rausholen.

Als Datum würde ich nen timestamp nutzen. Das ist glaub ich einfacher bei Berechnungen.
Einen counter würde ich nicht speichern sondern lieber jedes mal berechnen. Mit nem timestamp als Datum ist das easy.
Die ELOs pro match kannst du in die Spiel Tabelle packen. Da gehört die imo hin.

Beidem kann ich nur zustimmen. Solange sich die Daten bei "ein paar Tausend" bewegen und Performance keine Rolle spielt ist das der schnellste und effektivste Weg.

Und falls sich später was ändert... ja mei, dann ändert man die DB halt auch.

Grüße