2 Fragen zu Django Best Practice

[neophyte]

Einleitung:
Ich bin Python- und Django-Anfänger, habe aber schon einiges an Programmiererfahrung in anderen Sprachen. Auf Python bin ich gestossen, weil mein bisheriger Schwerpunkt Programmierung für den Desktop war, ich bisher erst ein grösserers Webprojekt hinter mir habe, das zwar erfolgreich mit PHP läuft, seinen Schwerpunkt aber eher nicht in der GUI hatte. Wollte dann mein nächstes Projekt ebenfalls mit PHP umsetzen, bin aber nie mit dem von mir gewählten Laravel warm geworden. So kam ich auf Python und Django und bin schwer begeistert. Mir geht es jetzt darum, dass ich bei folgenden Themen gerne eure Erfahrung anzapfen möchte, damit ich in die richtige Richtung laufe:

1. Ordnerstruktur
Mein aktuelles Projekt droht mittelgross zu werden, bin beim Design der Datenbanktabellen bei 58 Tabellen angelangt und es werden definitiv noch mehr. Das Projekt braucht eine solide Struktur - in der DB bin ich sattelfest, aber in Django noch nicht. Es werden mehrere Apps die ineinander verzahnt sind, jede App mit zig Models/Klassen/Views. Ist es egal, wie ich die Ordner strukturiere oder gibt es da best practices? Damit es übersichtlich bleibt würde ich zB gerne alle Klassen und Views in eigene Unterordner legen:
appname/views
appname/classes
Passt das so oder hat das Nachteile? Kann man das mit den Models auch so machen oder sollen die lieber in einem einzigen File models.py bleiben?

2. Standard-Django-Tabellen für User, Sessions, Berechtigungen etc
Ich verwende bei meinen Tabellen ein eigenes Benennungsschema, habe also in jedem Model im Meta ein db_table='xyz'. Ich würde das aus Gründen der Konsistenz auch gerne für alle Django-Standard-Tabellen wie auth_group etc machen. Ich habe mir den Abschnitt in der Doku schon durchgelesen (Customizing authentication in Django), kann mich mangels Erfahrung aber nicht entscheiden, ob es klüger ist, die Tabellen beim Originalnamen zu belassen und eine eigene Tabelle mit den Zusatzinfos zu machen (OneToOneField) oder doch gleich eine eigene Klasse und die in AUTH_USER_MODEL eintragen.
Was sind die langfristigen Vor- und Nachteile der beiden Herangehensweisen?
Ich arbeite derzeit noch direkt mit der Datenbank, also ohne eine einzige Migration durchgeführt zu haben (ausser in einem kleinen Testprojekt), bin also noch völlig frei in der Entscheidung. Die Apps sind übrigens absolut spezifisch, nicht wiederverwendbar und miteinander verzahnt.

Danke fürs lesen von soo viel Text!

[sparrow]

Es wird in etwa so laufen: Du wirst das Projekt anfangen. Dann wirst du während des Projektes lernen. Dann wirst du alles wegwerfen und neu machen.
Je früher du das siehst, desto einfacher wirst du dich hinterher von dem lösen können, was du fabriziert hast.
Ging allen so.

Ich wäre auch mit dem Aufteilen auf verschiedene Apps vorsichtig. Eigentlich™ sollte eine App in Django immer ohne Abhängigkeiten läuffähig sein.

Was genau sollen denn "Classes" sein?
Man kann sowohl Views als auch Models in verschiedene Module aufteilen. Ab einer sonst unübersichtlichen Größe ist das sinnvoll.

58 Tabellen verleiten mich zu der Annahme, dass das Datenbankschema kaputt ist.

Ein eigenes Namesschema für Tabellen würde ich auf gar keinen Fall verwenden.
Die einzige in meinen Augen sinnvolle Verwendung vom db_table-Attribut ist nur, wenn man intern Tabellen in einem Projekt umhängt (und das zeugt von Fehlplanung) oder wenn man ein Projekt auf eine bereits vorhandene, produktiv verwendete Datenbankstruktur setzt.
Beides ist bei dir nicht der Fall.
Ich würde sagen, lern mit Djangos ORM umzugehen, schreib vernünftige Modelle und überlass den Datenbankkram Django. Gerade wegen den Migrationen und ähnlichem. Man möchte ja eben nicht Dinge an mehr als einer Stelle pflegen.

Es ist meiner Erfahrung geschuldet, dass "ich habe ein eigenes Namensschema" oft einfach andere Worte für "ich benutze schlechte Namen" sind.
Kann bei dir anders sein. Würde mich aber tatsächlich positiv überraschen.

[neophyte]

58 Tabellen verleiten mich zu der Annahme, dass das Datenbankschema kaputt ist.

Man muss Foren einfach lieben. Nur eine einzige Anmerkung zu dem ganzen: auf Datenbanken bin ich seit >20 Jahren unterwegs und habe Systeme beachtlicher Grösse designed und programmiert. Nein, 58 Tabellen heisst nicht, dass das Design kaputt ist, es heisst dass es sauber, performant und von einer gewissen Grösse ist.

Django-Anfänger != Programmier-Anfänger.

[__blackjack__]

@neophyte: Man kann auch mehr als 20 Jahre kaputte Datenbankentwürfe gemacht haben. Dass es sauber, performant und von einer gewissen Grösse ist, wird nicht durch 58 Tabellen ausgesagt. Das sind andere Kriterien.

[neophyte]

Genau lesen. Deshalb schrieb ich ja und von einer gewissen Grösse. Seufz. Es ging hier um Systeme mit hunderten von Usern die 8h am Tag da Daten rein klopfen, nicht um eine Handy-App.
Ich bin hier raus.

[__blackjack__]

@neophyte: Das habe ich gelesen. Und auch wiedergegeben. Hast Du das nicht gelesen?

[sparrow]

@neophyte: So ist das. Man fragt etwas und dann bekommt man eine Antwort. Nichts davon ist abwertend. Du hast nach einer Meinung gefragt und eine bekommen.
Ich verstehe auch nicht, warum eine gewisse Größe in Mengen von Benutzern angegenen wird - und das etwas mit dem Datenbankschema zu tun hat. Das Datenbankschema ist unabhängig von der Anzahl der Benutzer. Oder bekommt bei dir jeder Nutzer seine eigene Tabelle? Weil das wäre dann ja schon kaputt.

[noisefloor]

Hallo,

die Anzahl der Daten und User ist doch für die Anzahl der Tabellen total irrellevant. Wenn hunderte von Usern z.B. ihre Temperatur- und Niederschlagsdaten in die DB eintragen, dann sind 58 Tabellen ca. 56 zu viel. Wenn du ein ERP System hast, dann sind 58 sicherlich OK bis eher zu wenig.

Da fehlt halt der Kontext.

Gruß, noisefloor

[Kebap]

Jetzt hat er seinen Account schon wieder gelöscht. Da lohnt sich eine Antwort wohl eher weniger.

[nezzcarth]

Nur eine einzige Anmerkung zu dem ganzen: auf Datenbanken bin ich seit >20 Jahren unterwegs und habe Systeme beachtlicher Grösse designed und programmiert. Nein, 58 Tabellen heisst nicht, dass das Design kaputt ist, es heisst dass es sauber, performant und von einer gewissen Grösse ist.

Ich glaube, das ist vielleicht schon, wo das Missverständnis anfängt, denn bei Django sind deine Kenntnisse im Datenbankdesign nur teilweise gefragt und, wenn ich mir die Diskussion hier angucke, vielleicht sogar ein Stück weit hinderlich. Bei der Verwendung von Django schreibst du nur Modelle in Form von Klassen und das ist das Level auf dem deine deine Interaktion mit der DB im Wesentlichen auch schon aufhört. Wie das konkret in der Datenbank dann in Form von Tabellen abgelegt wird, wie die heißen und wie viele das sind, kann dir egal sein. Das ist im Grunde nur ein Implementierungsdetail, das dich nicht kümmern braucht (bzw. wenn man selbst Erfahrung im Tabellendesign hat: vielleicht nicht kümmern darf).

Die vorgeschlagene Ordnerstruktur, insb. was "classes" angeht, halt ich nicht für so überzeugend.Was man aber machen kann, ist mit Packages arbeiten. D.h. statt einer einzigen models.py machst du einen Ordner Models, in dem du eine __init__.py anlegst und dann deine Modelle in einzelne Dateien aufgliedern kannst. Das funktioniert auch mit anderen Komponenten, die dir das Scaffolding standardmäßig als Modul anlegt und ist z.B. für die settings bei größeren Projekten weit verbreitet.

Wenn du ein Beispiel für ein komplexeres Projektlayout für Django sehen willst, kann man sich auch mal den django-cookiecutter ansehen.