Projekt Zeitmanagement

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

__deets__ hat geschrieben: Wie immer milde Meckereien, bzw. Verbesserungsvorschlaege:
Ich steh auf milde Meckereien. Deswegen bin ich hier :mrgreen: Danke fürs Feedback!
Die Kommasetzung ist zugegebenermaßen ungewöhnlich, hilft mir persönlich aber bei der Wartung des Codes. Setze ich die Kommata immer an die erste Position, stehen sie immer untereinander und immer am gleichen Fleck. So sehe ich sofort, wenn ein Komma fehlt oder überschüssig ist, wenn sie am SQL was geändert hat. Ich kann es künftig aber gerne auch klassisch schreiben, sofern ich dran denke :wink:
Statt in der Methode ewig lange SQL-statements zu haben, wuerde ich eher eine Liste auf Modulebene anlegen, "CREATE_STATEMENTS", und ueber die rueberlaufen, und die dann abfeuern
Du meinst also ein Modul bestehend lediglich aus einer Liste mit allen nötigen SQL Statements, die dann in den Python Funktionen nur mit Liste[Index] angesprochen werden? Klingt nice, aber wie ist das dann bei Parametern, die in das SQL reinmüssen? Deren Verwendung wird durch die Auslagerung in ein Modul ja eher erschwert, oder?
Deinen letzten Punkt blick ich ehrlich gesagt nicht :K
Sirius3
User
Beiträge: 17710
Registriert: Sonntag 21. Oktober 2012, 17:20

@T.T. Kreischwurst: Eingerückt wird mit 4 Leerzeichen pro Ebene, nicht mit Tabs. Jedesmal, wenn eine Instanz der Datenbankklasse erstellt wird, alles Tabellen zu erzeugen, halte ich für einen Fehler. Das sollte man bewußt, einmal beim erstellen einer neuen Datenbank machen. Zeile 51: wußte gar nicht, dass man nach einem INSERT ein fetch machen kann. Gerade ausprobiert, geht auch gar nicht. Das nimmt solangsam Ausmaße an, dass es ratsam wäre auf SQLAlchemy umzusteigen.
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

Ah ja da war etwas, das Blackjack mal erwähnt hatte.
Ich kann jetzt alles nochmal auf SQLAlchemy umschreiben, aber ist das wirklich sinnvoll? Erstens entstehen damit neue Fehlerquellen (weil unbekannt), zweitens dachte ich, ich lerne das ganze erstmal auf die rudimentäre, harte Tour, bevor ich Hilfsmittel benutze, mit denen ich bestimmte Fehler nicht mache. Ich bekomme daher eher immer stärker das Gefühl, dass die ganze Sache keinen Sinn hat. Ich komme hier zunehmend vom 100. ins 1000. und stelle fest, dass ich weder einen Plan von meinem Programm habe, noch einen erstellen kann weil ich keine Ahnung von objektorientiertem Entwurf habe und in letzter Konsequenz nicht begreife, was ORM eigtl. ist und was das für einen Vorteil bringen soll.
Vor diesem Hintergrund dann Prinzipien und Systeme anwenden und ausprobieren zu wollen, die man eigtl. nicht begreift, erscheint mir immer weniger sinnvoll. Wahrscheinlich muss ich erstmal viel mehr lernen, wobei ich nicht weiß, wo ich anfangen soll :K
Zuletzt geändert von T.T. Kreischwurst am Dienstag 18. April 2017, 17:09, insgesamt 1-mal geändert.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Bezueglich der statements: die sollen nicht (notwendigerweise) ausgelagert, aber getrennt vom Code werden;

Code: Alles auswählen


CREATE_TABLE_STATEMENTS = [
"""create table foo (
....
)""",
"""create table foo (
....
)""",

]

...

for statement in CREATE_TABLE_STATEMENTS:
     cursor.execute(statement)


Damit wird in meinen Augen der Code klarer - ich kann den losgeloest von deinen aufwaendig (was gut ist) formatierten SQL statements verstehen.

Das lohnt natuerlich nur bei statements die keine oder immer die gleichen Parameter haben, und wenn man eben wirklich mehrere hat - ich wuerde das nicht aus Prinzip empfehlen, sondern wirklich nur fuer die Anlage der DB.

AFAIK kann man sogar multi-statement absetzen, und statt einer Liste mehrere durch Semikola getrennte Statements in einen String schreiben.

Dann hat man einen Block, den man sogar per C&P von Hand in sqlite eingeben kann, wenn man das mal will.
Antworten