Datenbank für eine Quiz App?

Registriert
Nov. 2020
Beiträge
2
Hey meine lieben Programmier-Freunde,

ich hätte eine kleine Frage bezüglich Datenbanken.

Ich bin derzeit dabei, mit ein paar Freunden eine Quiz-App zu programmieren. Als Programmiersprache benutzen wir "Flutter". Hier haben sich bisher zum Glück keine Probleme ergeben.
Allerdings überlegen wie derzeit, wie man die ganzen Quiz-Fragen verwaltet...?
Ich kenne mich mit dem Thema Datenbanken noch nicht so gut aus, aber gerade ist meine Idee, eine MySQL Datenbank zu erstellen. Dann quasi Fragen in diese Datenbank einpflegen und immer jeder Frage eine Antwort zuzuordnen. Dann fügt man diese Datenbank irgendwie in die App ein und wenn dann jemand die Quiz-App spielt, werden zufällig Fragen aus dem Datenbank-Pool gestellt.

Ist das so theoretisch umsetzbar? Kann hier jemand grob anschneiden, auf was ich achten muss?

Ich Danke euch im Voraus und wünsche euch noch einen erfolgreichen Tag, bleibt alle gesund! :)

Viele Grüße

Lukas
 
Uff, die SQL API von Flutter sieht echt maximal gruselig aus: Link [PS.: Ist das nicht einmal DBMS-Agnostisch und nur sqlite spezifisch? Hätte gedacht, dass sei standard heute.]
Ihr habt mein Beileid.
Achten auf: In solchen Links ALLE WARNUNGEN lesen.
MySQL, SQLite, Postgresql, ... für euch erst einmal egal.
Achte darauf, die Datenbank zu Normalisieren. Das Thema ergibt in der Theorie Null Sinn wenn man zum ersten mal darüber liest, aber ihr wollt definitiv darauf achten, die sog. dritte Normalform einzuhalten.
 
Ja kann man so machen. Wenn ihr keinen Server habt, auf dem ihr die Fragen dann verwaltet, könntest du dir SQlite angucken. Ist das selbe nur ohne Server.
Der Vorteil an einem Server wäre natürlich, dass man den Spielern immer neue Fragen hinzufügen kann.
 
Im ersten Schritt würde ich eine SQLite-DB nehmen. So bleibt die Anbindung lokal und man muss nicht gleich mit einer DB im Netzwerk/Internet hantieren, was wieder einen Rattenschwanz nach sich zieht.
Laut diesem Link ist "Moor" etwas, was man sich angucken könnte.
 
Departet schrieb:
Der Vorteil an einem Server wäre natürlich, dass man den Spielern immer neue Fragen hinzufügen kann.
Das hat erstmal nichts mit SQLite zu tun, sondern ist nur der heute üblicherweise anzutreffende Anwendungsfall. Wenn es keine DBMS-agnostische API gibt bei Flutter, dann ist es aber vermutlich sinnvoll, direkt MariaDB oder Postgresql zu verwenden.
 
Hey Leute.

Wow. Erst einmal ein riesen Danke Schön an all eure schnellen Antworten!

Also ein Server - bzw. eine Möglichkeit zu regeln, dass Nutzer Fragen nur ein mal erhalten, ist definitiv geplant.

Was ich jetzt für mich mitnehmen kann:

Es müssen viele Sachen beachtet werden und es wird sehr kompliziert, da müssen wir aber durch, da es keinen anderen Weg gibt.
Die Datenbank sollte Normalisiert werden.
Man sollte direkt MariaDB oder Postgresql verwenden.

Ich hoffe ich habe das alles so einigermaßen richtig aufgefasst?
 
  • Gefällt mir
Reaktionen: BeBur
Wenn du einen Server betreibst, auf dem die Datenbank läuft, dann von der Applikation aus nicht direkt auf die DB zugreifen, sondern z.B. über eine davor gelagerte (REST)-Schnittstelle.
 
  • Gefällt mir
Reaktionen: KitKat::new()
BeBur schrieb:
Uff, die SQL API von Flutter sieht echt maximal gruselig aus: Link [PS.: Ist das nicht einmal DBMS-Agnostisch und nur sqlite spezifisch? Hätte gedacht, dass sei standard heute.]

Es ist nicht möglich und wird es vermutlich auch nie sein, dass man sich mit einer Android-App direkt an eine Datenbank verbindet. SQLite ist dazu gedacht, um seine Daten lokal geordnet zu speichern, sofern die Key-Value-Pairs dazu nicht ausreichend sind. Man kommt also nicht drumherum eine REST-API (oder etwas anderes in dieser Richtung) zu entwickeln.
 
  • Gefällt mir
Reaktionen: KitKat::new()
KingLM97 schrieb:
Es ist nicht möglich und wird es vermutlich auch nie sein, dass man sich mit einer Android-App direkt an eine Datenbank verbindet. SQLite ist dazu gedacht, um seine Daten lokal geordnet zu speichern, sofern die Key-Value-Pairs dazu nicht ausreichend sind. Man kommt also nicht drumherum eine REST-API (oder etwas anderes in dieser Richtung) zu entwickeln.
Ich spreche davon, dass anderorts die API z.B. so aussieht:
Code:
Dog.create name: 'Fido', age: 35           # Creates a new row in table 'dogs'
Dog.where age: 25                          # Equals to: 'SELECT * FROM dogs WHERE age = 25'
Die Docs die ich da spontan gesehen und verlinkt hatte sahen verglichen damit etwas unübersichtlich aus. DBMS-agnostisch ist das aber womöglich.
 
Lukas Hausmann schrieb:
Ich hoffe ich habe das alles so einigermaßen richtig aufgefasst?

Generell halte ich es für sinnvoll, mehr in Konzepten zu denken als in genauen Umsetzungen.

Grob dargstellt gibt es zwei Ansätze (und einige dazwischen):
1. Die Fragen werden von einem lokalen Speicherort (= Smartphone) abgefragt.
2. Die Fragen werden von einem externen Speicherort (= Internet) abgefragt.

Der nächste Schritt ist dann, selbstständig darüber nachzudenken, welche Vor- und Nachteile diese beiden Ansätze haben könnten. Und dann wie diese Vor- und Nachteile sich mit den Anforderungen an deine Anwendung verbinden lassen.
 
  • Gefällt mir
Reaktionen: KitKat::new()

Ähnliche Themen

Zurück
Oben