jibbow / db-wahlinformationssystem Goto Github PK

Ja hmm, da hab ich was verbockt, weil ich nicht wirklich verstanden habe, was in dem Ergebnis der Top-10 Query eigentlich steht 😂

Absolutes Chaos im frontend gerade. Sollte mal bisschen aufgesplittet werden.

evtl. gut lösbar über stored procedures?

Das Schema ist gerade auf einem uralten Stand und muss - nachdem issue #4 fertig ist - geupdated werden.

Entweder per Hand in unserem Lucidchart (kann mal jemand den link hersuchen und hier posten bitte?) oder evtl gibt es auch eine Möglichkeit, es aus HANA Studio zu exportieren?

http://localhost:8000/ueberhangmandate/1/14/2018

Grund: es kann gut sein, dass mein Azure Guthaben mal zu früh aufgebraucht ist und wir spontan umziehen müssen. Außerdem hätten wir dann eine Absicherung, wenn jemand mal was an der Datenbank verbockt 😄

Was gibt es zu tun?
Alle Tabellen sollten als csv exportiert werden (issue #4 muss vorher erledigt werden). Da die Tabellen zu groß fürs git repo sind, sollten danach alle einzeln gezipped werden.

Es existiert bereits ein db-provisioner.py Script, mit dem man Daten in die DB laden kann. Allerdings ist es gerade unnutzbar langsam, da es jedes tupel einzeln einfügt. Entweder soll hier das Script - falls möglich - angepasst werden, oder ein neues Script entwickelt werden falls der python HANA Treiber es nicht anders zulässt.
Außerdem muss das neue Script on-the-fly vorher die zip Dateien auspacken und dann die Daten in die DB laden. Die connection Parameter sollten aus der .env Datei gelesen werden.

Eine neue Route zur Abgabe einer Stimme anlegen.
Außerdem müssen evtl neue routen angelegt werden, um die Liste an Kandidaten zu erstellen.

Eine weitere Aufgabe ist es, sich ein sicheres Konzept zur Stimmabgabe zu überlegen.
Dabei soll
Niemand zweimal wählen können und auch kein wahlbetrug stattfinden dürfen. Außerdem darf die Stimme nicht mit dem Nutzer korreliert werden können.

• raussuchen
• in die DB schreiben
• Query schreiben für Wahlbeteiligung
• Schema anpassen

Die sind im Moment noch nicht da, aber die Query und das Backend sollte passen. Also hier fehlt nur noch das Frontend

Mit den Lasttests waren wir noch nicht ganz fertig und wir sollten es auf jeden Fall noch für größere 'n' testen.

Alice und Enis hatten da einen guten Ansatz für die Verteilung von t und n.

In der Datenbank gibt es einige unnütze Tabellen und manche Tabellen wie zB PARTEI enthalten nicht alle/unvollständige Werte. Außerdem ist die Benennung der Spalten nicht konsistent.
Nach der Umbenennung muss darauf geachtet werden, dass die SQL queries im backend entsprechend angepasst werden.

Ziel ist es, eine "saubere Datenbank" zu haben.

Was war da genau @carnivean ? Irgendwas hat dir da doch Kopfschmerzen bereitet?
Ah und übrigens müssen wir die gar nicht auf aggregierten Daten ausführen ;)

Falsch im frontend oder query liefert das falsche?!

Oben genannte Query ist fehlerhaft, da sich das mapping der Stimmkreise von 2013 auf 2018 geändert hat.

Wir sollten auf jeden Fall punktuell queries testen.

Das kann man entweder direkt im backend machen (da kann @Jibbow helfen) oder irgendwie extern als eigenen Script oder via Jmeter würde es glaube ich auch gehen 😄

http://localhost:8000/stimmverteilung/131/2013 gibt ein leeres Ergebnis zurück. Für 2018 passt es allerdings...

Man hat gesehen, dass die queries der anderen teams teilweise schneller laufen. Heißt also für uns: das können/müssen wir toppen! 😄

Auf jeden Fall gibt es viel Optimierungsbedarf für jede query. Gerne auch sub-issues hierfür erstellen.