Lernen anhand eigener Projektidee - Vorgehen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
velocity911
User
Beiträge: 6
Registriert: Sonntag 11. Dezember 2016, 14:48

Hallo liebes Forum,

schön den Weg zu euch gefunden zu haben. Ich bin Physiker und möchte gerne auf eigene Faust etwas mit SQL, mit Phyton und ggf. mit ein bisschen Statistik/Auswertung machen. Ich habe ein paar Grundlagen im programmieren weil ich numerisch physikalische Systeme in C++ entwickelt habe. Dazu habe ich mal vor 3 Jahren ein größeres Arduino projekt umgesetzt.



Das ganze möchte ich gerne mit einem kleinen Nutzen für unseren Verein verbinden. Dazu habe ich mir ein Projekt überlegt, bei dem zu jeder wöchentlichen Vereinssitzung, die Mitglieder eine live-Umfrage abschließen können und diese dann am Ende der Veranstaltung ausgewertet vorliegen soll. Die Fragen sollen vor der Sitzung vom Vereinsvorstand ausgewählt werden. Es wäre schön am Endes des Jahres alle Umfragen rückblickend in einer History speichern zu können.

Folgendes Bild soll das Projekt veranschaulichen:
Bild

Meine Fragen an euch:

Ist das Projekt mit Phyton/Flask und SQL umsetzbar?


Wie kann ich nach einer Umfrage die Auswertung vornehmen und diese auf einer Report-page darstellen?


Was wären die ersten Schritte, wo sollte ich Anfangen? (Phyton und eine IDE dafür sind bereits installiert)?
Meine Idee dazu war, zuerst einen SQL Server aufzusetzten und dann zu lernen, wie ich mit Phyon auf eine Datenbank zugreifen und diese Verändern kann.

Über eine Hilfe von euch, damit ich Zielgerichtet lernen kann, würde ich mich freuen.

Liebe Grüße, velo
Sirius3
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

@velocity911: solche ein Projekt ist mit Python/Flask umsetzbar. Phyton ist dafür aber eher nicht geeignet. Am besten Fängt man damit an, die Abhängigkeiten der Daten festzulegen, darauf aufbauend ein Datenbankschema zu entwickeln und dieses dann als Objekte mit SQLAlchemy zu modelieren. Hat man die Abfragen gründlich getestet und mit vielen Beispieldaten gefüttert, kann man Anfangen ein schönes Webinterface draufzusetzen.
BlackJack

@velocity911: Ja das ist in Python und mit Flask umsetzbar.

Wie die Auswertung im Detail passiert hängt vom Datenbankentwurf ab, und der wiederum davon was Umfragen ganz konkret bedeuten. Also nur Ja/Nein-Fragen? Gibt es Benutzer und werden deren individuellen Antworten gespeichert oder kann jeder ohne Anmeldung etwas wählen?

Die Aufbereitung der Auswertung kann man auch sehr verschieden umsetzen. Durch einfache Balken aus Unicode-Blockzeichen, über Tabellenzellen oder <div>-Elemente mit Hintergrundfarbe und einer Breite die in Prozent angegeben wird, über Grafiken die dynamisch auf dem Server generiert und ausgeliefert werden, bis zu JavaScript-Bibliotheken die die Diagramme erst im Browser zeichnen.

SQL-Server aufsetzen wäre nicht mein erster Schritt. Den ersten Prototypen kann man auch mit SQLite erstellen. Für eine SQL-Datenbank würde ich auf die Flask-SQLAlchemy-Erweiterung setzen. Dann braucht man sich auch nicht mit SQL-Abfragen als Zeichenketten herumschlagen.

Ich würde als erstes das Tutorial in der Python-Dokumentation durcharbeiten. Das bietet einen Rundgang durch die Sprache und wenn man schon eine andere Sprache kennt, sieht man Gemeinsamkeiten und Unterschiede.

Dann das Flask-Tutorial. Da lernt man das Grundgerüst für eine Webanwendung mit Flask kennen und auch wie man ”manuell” mit einer SQL-Datenbank arbeitet. Die verwenden dort auch SQLite. Man braucht dafür keinen Server und das `sqlite3`-Modul ist bereits Bestandteil der Standardbibliothek von Python.

Dann kannst Du Dir die Flask-SQLAlchemy-Dokumentation vornehmen um zu lernen wie man das SQL los wird und Objekte auf Datenbanktabellen abbildet.

Konkret für Deine Anwendung müsstest Du den Datenbankentwurf machen. Also die Entitäten, ihre Eigenschaften, und wie die Entitäten miteinander in Beziehung stehen. Das hängt davon ab was für Anfragen an die Daten gestellt werden. Wenn es beispielsweise konkrete Benutzer gibt, dann braucht man dafür eine Entität im Datenbankentwurf. Wenn es nur Ja/Nein(/Vielleicht)-Fragen gibt, dann reicht eine Entität für Umfragen aus. Wenn es pro Umfrage individuelle Auswahlmöglichkeiten gibt, dann für Antwortmöglichkeiten eine Entität einführen. Wie die mit der Umfrage-Entität in Beziehung steht, hängt davon ab ob eine konkrete Auswahlmöglichkeiten später noch einmal geändert werden kann und wie man dabei in der Programmlogik damit umgehen will. Also ob es okay ist wenn sich dadurch der Text bei allen bestehenden Umfragen ändert. Oder ob es okay ist mehrfach den gleichen Text in der Datenbank zu haben. Oder ob man in der Programmlogik sicherstellt, das Änderungen nicht zu doppelten Einträgen führen.

Die Verwendung der Anwendung und damit der Datenbank sollten möglichst am Anfang festgelegt werden. Datenbankentwürfe nachträglich zu ändern kann Probleme mit sich bringen oder zumindest aufwändig sein. Weil man dabei ja immer die bereits bestehenden Daten konvertieren muss.

Für die Clientseite würde ich ein CSS-Rahmenwerk wie Bootstrap verwenden.

Um Sirius3 zweiten Satz noch mal zu unterstreichen: Ganz am Anfang solltest Du 100 Mal: „Es heisst Python und nicht Phyton“ an die Tafel schreiben. ;-)
velocity911
User
Beiträge: 6
Registriert: Sonntag 11. Dezember 2016, 14:48

Am besten Fängt man damit an, die Abhängigkeiten der Daten festzulegen, darauf aufbauend ein Datenbankschema zu entwickeln und dieses dann als Objekte mit SQLAlchemy zu modelieren. Hat man die Abfragen gründlich getestet und mit vielen Beispieldaten gefüttert, kann man Anfangen ein schönes Webinterface draufzusetzen.
Wie die Auswertung im Detail passiert hängt vom Datenbankentwurf ab, und der wiederum davon was Umfragen ganz konkret bedeuten. Also nur Ja/Nein-Fragen? Gibt es Benutzer und werden deren individuellen Antworten gespeichert oder kann jeder ohne Anmeldung etwas wählen?
Sagen wir die Datenbank soll 8 Ja/nein Fragen beinhalten,1 Frage bei der Man aus nem Drop-down Menü Text auswählen kann und 1 Frage, die eine Texteingabe erfordert. Dabei sollen die Personen annonym bleiben, d.h. von einer Anmeldung soll abgesehen werden. Die Daten sollen einfach über einen submit buttom in die Datenbank geschrieben werden. Was wären dann die Entitäten? 1 für Session ID (ich nehme mal an, dass jeder Seitenaufruf über ne ID o.Ä eindeutig bestimmt ist) mit 8 Ja/Nein Spalten, 1 für Session ID und die drop-down Möglichkeiten und 1 für ID und Text?

Abfragen brauch ich dann erst wenn die eigentliche Statistik gemacht werden soll bzw. ein Report erstellt wird oder?

Das vorgeschlagene vorgehen BlackJack finde ich gut, das tutorial in der Dokumentation gefällt mir !

Achso, ein kleiner Knicks noch für das falsche Python -
BlackJack

@velocity: Hm, so ganz klar ist mir das noch nicht. Du sagst die Datenbank soll … und dann kommt eine Beschreibung von Fragen die eher danach klingt als gelte sie nicht für die Datenbank sondern für *eine* Umfrage. Und dann ist die Anzahl der Fragen eigentlich egal, denn das würde man eher nicht in einen Datensatz packen, also 8 Spalten für 8 Ja/Nein-Fragen, sondern eine eigene Tabelle für die Frage(n) und Antworten.

Anmeldung und anonym antworten muss sich ja nicht ausschliessen. Man speichert dann halt nur die Antworten ohne Bezug auf den Benutzer, man kann aber bei der Benutzer/Umfrage-Kombination vermerken, dass der Benutzer bereits eine Antwort abgegeben hat, damit man sicherer verhindern kann als mit einem Cookie das jemand mehrmals teilnimmt.

Abfragen brauchst Du auch schon wenn der Benutzer die Umfrage sehen will, denn die Daten dafür stehen ja in der Datenbank, und wenn er seine Antwort speichert, denn die muss ja in die Datenbank geschrieben werden. Die Auswertung passiert dabei ja fast schon, denn wenn die Antworten anonym abgegeben werden, dann speichert braucht man die Antworten (ausser den Text) ja nicht als eigenen Datensatz speichern, sondern kann gleich Zähler aktualisieren. Für die Auswertung braucht man diese dann nur noch abfragen und irgendwie passend darstellen.
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

was du auch bedenken solltest: wenn du keinerlei Nutzerdaten speicherst, könnte der gleiche Nutzer die Umfrage auch 10x ausfüllen und abschicken.
Wenn das nicht gewünscht ist (gehe ich mal von aus), solltest du vielleicht noch speichern, welcher Nutzer welche Umfrage schon gemacht hat. Was ja nicht heißt, dass man die Antworten auch einem Nutzer zuordnen muss.

Gruß, noisefloor
BlackJack

Nicht zu speichern welche Antwort von wem ist, bedeutet dann übrigens auch, dass der Benutzer seine Antwort(en) nicht mehr ändern kann wenn er sie abgeschickt hat. Hier könnte man vielleicht eine ID für die Antwort beim Benutzer als Cookie speichern (kryptografisch signiert), so dass er, solange er das Cookie hat, seine Antworten noch einmal überdenken kann.
velocity911
User
Beiträge: 6
Registriert: Sonntag 11. Dezember 2016, 14:48

BlackJack hat geschrieben:@velocity: Hm, so ganz klar ist mir das noch nicht. Du sagst die Datenbank soll … und dann kommt eine Beschreibung von Fragen die eher danach klingt als gelte sie nicht für die Datenbank sondern für *eine* Umfrage. Und dann ist die Anzahl der Fragen eigentlich egal, denn das würde man eher nicht in einen Datensatz packen, also 8 Spalten für 8 Ja/Nein-Fragen, sondern eine eigene Tabelle für die Frage(n) und Antworten.
Eine Umfrage soll wöchentlich mit anderen Fragen durchgeführt werden und die Ergebnisse jeder Umfrage sollen später verfügbar sein.


Die Teilnehmer sind die Vereinsmitglieder. Die Abstimmung soll von diesen direkt vor Beginn einer Vereinssitzung per Laptop/Mobile vorgenommen werden und die Auswertung noch während der Vereinssitzung vorliegen.
Sirius3
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

@velocity911: und wie hast Du Dir die Tabellen vorgestellt, die diese Umfragen speichern? Ich glaube, wenn Du Dir die Fragen stellst, "wie finde ich die Fragen der aktuellen (oder einer vorangegangenen) Umfrage heraus?" oder "was ist das Umfrageergebnis der Frage xy?" wirst Du relativ schnell merken, ob das Design, das Du Dir ausgedacht hast, auch wirklich praxistauglich ist.
velocity911
User
Beiträge: 6
Registriert: Sonntag 11. Dezember 2016, 14:48

Sirius3 hat geschrieben:@velocity911: und wie hast Du Dir die Tabellen vorgestellt, die diese Umfragen speichern? Ich glaube, wenn Du Dir die Fragen stellst, "wie finde ich die Fragen der aktuellen (oder einer vorangegangenen) Umfrage heraus?" oder "was ist das Umfrageergebnis der Frage xy?" wirst Du relativ schnell merken, ob das Design, das Du Dir ausgedacht hast, auch wirklich praxistauglich ist.
Kann man nicht für jede Umfrage eine eigene Tabelle (mit Datum) in der DB speichern und so die vergangenen Umfragen managen?

Ich habe nun schon ein paar Tage mit python gearbeitet (das tutorial aus der Dokumentation) und muss sagen, es macht viel Spass.

In ein paar Tagen möchte ich mit SQL anfangen und habe schonmal geschaut, was ich sinnvoll als Datenmanagementsystem nutzen könnte. Meine Frage an euch:

Was würdet ihr empfehlen zu benutzen, wenn das Ziel ist, SQL zu verstehen und ggf. auch später weitere Projekte umzusetzten.

Es stehen zur Auswahl: MySQLdb, SQLlite und SQLAlchemy.

Bei SQLAlchemy scheinen mir die Query hinter der Objectsprache versteckt zu sein, sodass ich befürchte man versteht von SQL selbst dann nichtmehr soviel.

Mfg
Sirius3
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

@velocity911: wenn Du wirklich SQL lernen willst, dann kommst Du mit SQLAlchemy wirklich nicht weit. Das ist ja gerade der Vorteil, weil man sich nicht mit SQL und seinen Dialekten herumschlagen muß (und man kann relativ leicht das Datenbanksystem wechseln). SQLite kann man ohne große Installation sofort nutzen. Wenn man auch noch Rechtemanagement (was bei jedem System wieder komplett anders ist) lernen will, muß man wohl oder übel auf MySQL/MariaDB oder PostgreSQL aufsetzen. Willst Du Dein Projekt möglichst schnell und gut umsetzen, nimm SQLAlchemy. Willst Du später SQL lernen, dann mach das später.

Tabellen sind etwas fixes. Sie werden einmal am Anfang angelegt. Das Datum in den Tabellennamen zu stecken und viele gleichartige Tabelle zu erzeugen ist immer mal wieder eine Idee von Anfängern, die man möglichst schnell loswerden sollte.
BlackJack

@velocity911: Werte gehören *in* die Tabellen, nicht in Tabellen- oder Spaltennamen. Denn dort kann man nicht mittels SQL darauf operieren.

Zum grundlegenden SQL verstehen kannst Du fast nehmen was Du willst, wobei eine wichtige Sache ist, dass es nicht *das* SQL gibt, weil abseits von einen Kern in dem sich die DBMS überschneiden, jedes seine Eigenheiten hat. Weshalb ich auch so auf SQLAlchemy stehe, das abstrahiert diese Unterschiede nämlich zu einem guten Teil. Da ist es dann egal ob ein DBMS tatsächlich den BOOLEAN-Datentyp kennt, oder das mit Zahlen simuliert, in SQLAlchemy kann ich trotzdem sagen eine Spalte hat den Typ BOOLEAN und bekomme auch `True` und `False` auf der Python-Seite heraus.

Als ich SQL/relationale Datenbanken (kennen)gelernt habe, wurde noch dringend zu PostgreSQL geraten, weil MySQL nicht alles konnte was in der Lehrveranstaltung thematisiert wurde. Keine Ahnung wie weit die mittlerweile aufgeholt haben. Vieles von dem Kram habe ich danach aber auch nie wieder gebraucht. MySQL reichte auch damals schon vielen aus. Das ist wohl auch ein bisschen Einstellunsgssache. Zum Beispiel ob und wenn ja wie viel der Geschäftslogik man direkt in der Datenbank haben möchte. Ich eher gar nicht, damit man die leichter austauschen kann, andere wollen am liebsten auch das Frontend gleich in der Datenbank haben. Verrückte! :-)

SQLAlchemy hat zwei Stufen. Einmal eine Objektschicht über SQL, das heisst da kann man sich SQL mit Objekten zusammenbasteln und braucht sich keine Sorgen machen, dass man beim SQL-Anweisungen per Zeichenketten zusammenstückeln Mist baut. Da ist man also noch sehr nah an SQL dran. Dabei werden dann auch schon die kleineren Unterschiede zwischen den DBMS und deren Python-Anbindungen ausgebügelt. Zum Beispiel wie man Platzhalter für Werte angibt.

Darauf baut der Object Relational Mapper (ORM) auf, mit dem man Tabellen und Beziehungen direkt auf Objekte abbilden kann und wo die Abfragen automatisch erzeugt und abgesetzt werden. Wo man aber auch einiges an Einstellungen vornehmen kann wann was und wie abgefragt wird.

In beiden Fällen kann man sich das SQL anschauen das erzeugt wird. Und auch beim ORM braucht man spätestens dann SQL-Kenntnisse wenn es um Optimierungen geht. Und auch bei M:N-Beziehungen, wenn man eine Zwischentabelle benötigt, ist man wieder eine Ebene tiefer. Man kann auch selbstgeschriebene Abfragen auf Attribute oder Objekte abbilden.
Benutzeravatar
Kebap
User
Beiträge: 686
Registriert: Dienstag 15. November 2011, 14:20
Wohnort: Dortmund

velocity911 hat geschrieben: Kann man nicht für jede Umfrage eine eigene Tabelle (mit Datum) in der DB speichern und so die vergangenen Umfragen managen?
Jede Umfrage oder jede einzelne ANtwort wird später eine einzelne Zeile in einer riesigen Tabelle, die du dir aber nie selbst ansehen musst, sondern dafür wird dein Programm da sein: Die notwendigen Daten aus der Datenbank zu holen und übersichtlich anzuzeigen. Man speichert in der Datenbank also möglichst effektiv und nicht möglichst übersichtlich, wie man zunächst vermuten könnte. Einige Grundlagen dazu wären empfehlenswert.
MorgenGrauen: 1 Welt, 8 Rassen, 13 Gilden, >250 Abenteuer, >5000 Waffen & Rüstungen,
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
velocity911
User
Beiträge: 6
Registriert: Sonntag 11. Dezember 2016, 14:48

Hallo, also Dank eurer Hilfe bin ich jetzt dabei die ersten Queries zu testen. SQLAlchemy ist echt super, die erste Lernkurve ist etwas steil, wenn man noch nie mit Datenbanken zu tun hatte, aber man kann viel dabei lernen.

Bisher habe ich 2 joined Tables erstellt und mit einzelnen Queries diese verändert bzw. ausgelesen.

Ich bin mir noch im unklaren, wie ich nun im Hinblick auf die Umfrage und das Webinterface meine Datenbankabfragen am besten Testen kann.

Bisher habe ich die Tables in loops mit content gefüllt und die queries mit if- abfragen und key-input initialisiert, aber ich habe keine Idee, wie die Funktionalität vom Abfragen später mit dem webinterface zusammenspielt.

Mein naives Vorgehen wäre jetzt, für jeden Button auf der Umfragepage, einen Button mit if+keyboardinput in Python zu simulieren und sie die gesamte Page struktur zu testen. Das wäre allerdings schon umfangreicher als ich es vermutet hätte zu beginn des Projekts :)

Wie testet man sowas "richtig" im Hinblick auf die spätere Verwendung?

Liebe Grüße, :D
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

es kommt drauf an, wie deine Webseite aufbaust, also ob du Checkboxen, Radiobuttons, Auswahlfelder oder Textfelder hast. Davon hängt ja ab, welchen Daten (bzw in welcher Form) du dann von der Webseite zurück bekommst. Danach müsstest du dann auch deine Tests aufbauen.

Wenn die Formulare nicht völlig trivial sind, dann solltest du überlegen, nicht noch ein Formular Framework dazwischen zu schalten. Das kümmert sich a) um's Erstellen der Formularfelder und b) um die Validierung der Eingabe. Recht gängig ist z.B. WTForms. AFAIK gibt es eine WTForms-Extension für Flask und auch eine direkte Anbindung von WTForms an SQLAlchemy.

Gruß, noisefloor
Sirius3
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

@velocity911: was meinst Du mit "die queries mit if- abfragen und key-input initialisiert"? Die "Geschäftslogik" sollte unabhängig von einer Oberfläche entwickelt und getestet werden, also eine Klasse Umfrage, mit Methoden zur Erzeugung, Teilnahme und Auswertung. Die Anbindung ans User-Interface besteht dann meist aus wenigen (3-5) Zeilen Code, für die ich mir normalerweise die Mühe spare, automatisierte Tests zu schreiben.

Wie sehen denn Deine Tabellen und bisherigen Tests aus?
Antworten