Hallo,
ich habe eine Webseite mit php, mysql, (java und flash zum Darstellen von Panoramen)
Das funktioniert ganz schoen, aber ich habe php einfach satt :-/
Mit Python hab ich etwas Erfahrung, frueher bisschen python 2.*, neuerlich hab das "Python 3"
Buch durchgearbeitet
(ausser die Kapitel GUI (da gab es Probleme mit Python 3 und tkinter unter Freebsd und auch unter Ubuntu), und ausser OO Programmierung (ich weiss, aber mir fehlt da immer die Abbildung meiner
Probleme nach OOA, und dann verwende ich eben Funktionen))
Und jetzt wuerde ich gern Python verwenden und hab beim Suchen Django und WSGI gefunden.
Ich kann nicht einschaetzen, bei welchem ich mich leichter tun wuerde, die jetzige Seite
zu migrieren. Fuer WSGI hab ich bisher auch nur Installationsanleitungen gefunden und kein Howto oder so. Bei Django hab ich irgendwie Angst um meine Datenbank.
Koennt Ihr mir Tips geben?
Viele Gruesse,
Torres
Was soll ich nehmen? Django oder WSGI?
NImm ein Microframework wie Flask oder Bottle. Rohes WSGI ist eher übel. Angeblich nicht zuuu kompliziert, aber nervig, weil man viel Code schreiben muss (habe da keine eigene Erfahrung mit). Da ist das Routing mittels Dekoratoren, wie man es bei den beiden genannten Frameworks hat, schon angenehmer. Den Rest kannst du dir selber aussuchen. Für Flask gibt es schon einige Plugins, die du bei Bedarf für bestimmte Anwendungsbereiche hinzu installieren kannst (die dann auch gut integriert sind), ohne dass du gleich das aufgeblähte Gesamtpaket a la Django nutzen musst.
-
noisefloor
- User
- Beiträge: 4179
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Es gibt aber noch viel mehr, siehe http://wiki.python-forum.de/Web-Frameworks oder http://wiki.python.org/moin/WebProgramming bzw. http://wiki.python.org/moin/WebFrameworks. Es ist ja nicht so, dass es da keine Auswahl gäbe
Wie snafu schon sagt, bieten sich aber auch Microframeworks an. Zumal du hier im Forum sowohl für Bottle als auch für Flask schnell und kompetent Hilfe bekommt. Ebenso aber auch für Django.
Gruß, noisefloor
Dazwischen fehlt aber ganz viel. WSGI ist quasi der unterste Level, Django ist eines der größten, komplette Framework schlechthin unter Pyhton.Und jetzt wuerde ich gern Python verwenden und hab beim Suchen Django und WSGI gefunden.
Es gibt aber noch viel mehr, siehe http://wiki.python-forum.de/Web-Frameworks oder http://wiki.python.org/moin/WebProgramming bzw. http://wiki.python.org/moin/WebFrameworks. Es ist ja nicht so, dass es da keine Auswahl gäbe
Wie snafu schon sagt, bieten sich aber auch Microframeworks an. Zumal du hier im Forum sowohl für Bottle als auch für Flask schnell und kompetent Hilfe bekommt. Ebenso aber auch für Django.
Wie wäre es dann mit einer Datensicherung?Bei Django hab ich irgendwie Angst um meine Datenbank.
Gruß, noisefloor
Hallo,
vielen Dank fuer die Antworten.
Ich dachte mir halt mit WSGI "zu Fuss" (aber "zu Fuss" hab ich das auch schon immer mit php gemacht, und da sehe ich dann fast kaum Grund zu einer Migration, ausser halt PYTHON)
Und ansonsten dachte ich mir eben Django "kann alles" - da muesste ich mich quasi um nichts mehr kuemmern.
Naja, ich weiss es nun noch immer nicht, mit Django hab ich aber mal das Problem, dass ich das repo nicht auschecken kann.
Die Seite mit dem Web Frameworks hatte ich mir durchgelesen. Vielleicht gucke ich mir die Sachen mal genauer an.
Viele Gruesse,
Torres
vielen Dank fuer die Antworten.
Ich dachte mir halt mit WSGI "zu Fuss" (aber "zu Fuss" hab ich das auch schon immer mit php gemacht, und da sehe ich dann fast kaum Grund zu einer Migration, ausser halt PYTHON)
Und ansonsten dachte ich mir eben Django "kann alles" - da muesste ich mich quasi um nichts mehr kuemmern.
Naja, ich weiss es nun noch immer nicht, mit Django hab ich aber mal das Problem, dass ich das repo nicht auschecken kann.
Die Seite mit dem Web Frameworks hatte ich mir durchgelesen. Vielleicht gucke ich mir die Sachen mal genauer an.
Viele Gruesse,
Torres
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Wieso willst Du da eine Entwicklerversion nehmen?torres hat geschrieben: Naja, ich weiss es nun noch immer nicht, mit Django hab ich aber mal das Problem, dass ich das repo nicht auschecken kann.
Zum Thema zu "Fuß":
Klar machen viele PHP-Programmierer viel zu Fuß; das liegt aber in der Sprache selber begründet, die eben als einziges relevantes Verbreitungsgebiet das Web hat. In Python fangen Tutorials ohne http, HTML usw. an, sondern können sich einzig und alleine auf Kontrollstrukturen, simples Rechnen, usw. konzentrieren. Ein PHP-Tutorial könnte ja auch mit Frameworks für PHP anfangen, aber das ist wieder schwierig, weil dann die Grundlagen fehlen. Theoretisch müsste man jedes Tutorial am Ende mit den Worten abschließen: "So, lieber Einsteiger, nun da Du die Grundlagen beherrschst, vergiss alles (inhaltliche) und suche Dir ein Framework, mit dem Du in Zukunft Deine Seiten erstellst"
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Also django hab ich mir nun soweit angeschaut und werde es leider nicht weiter verfolgen.
Das Admin Tool ist fuer meine Beduerfnisse unzureichend und ich habe keine
gute Dokumentation zur Erweiterung gefunden, von Kleinigkeiten abgesehen. Da aber
das Admin-Tool sehr wichtig fuer mich ist, gebe ich also auf. (was ich echt so schade finde)
Ohnehin beziehen sich die ganzen Tutorial alle nur auf solche kleinen Mini-Apps und gehen nicht
besonders tief (und sind alle irgendwie immer die gleichen Beispiele?!)... Und nur mit dem djangobuch stehe ich dann eben recht bald da und komme nicht
weiter, bin eben kein Einstein.
Jetzt gehe ich davon aus, dass die anderen Webframeworks auch nicht gerade besser sind und
schaue mir wsgi an, um es eben doch zu Fuss zu machen...
Aber ich merke schon, dass es vermutlich auf ein redesign in php hinauslaeuft.
diesmal frustrierte Gruesse,
Torres
Das Admin Tool ist fuer meine Beduerfnisse unzureichend und ich habe keine
gute Dokumentation zur Erweiterung gefunden, von Kleinigkeiten abgesehen. Da aber
das Admin-Tool sehr wichtig fuer mich ist, gebe ich also auf. (was ich echt so schade finde)
Ohnehin beziehen sich die ganzen Tutorial alle nur auf solche kleinen Mini-Apps und gehen nicht
besonders tief (und sind alle irgendwie immer die gleichen Beispiele?!)... Und nur mit dem djangobuch stehe ich dann eben recht bald da und komme nicht
weiter, bin eben kein Einstein.
Jetzt gehe ich davon aus, dass die anderen Webframeworks auch nicht gerade besser sind und
schaue mir wsgi an, um es eben doch zu Fuss zu machen...
Aber ich merke schon, dass es vermutlich auf ein redesign in php hinauslaeuft.
diesmal frustrierte Gruesse,
Torres
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
@torres: Also zum einen ist es immer verkehrt zu pauschalisieren (s. die Sarazin-Debatte), zum anderen kann ich Deine Schlüsse nicht nachvollziehen!
Ich kenne Deine Anforderungen nicht, daher mag es schon sein, dass Django zu starr und unflexibel für Dich ist. Dann ist die Konsequenz aber bestimmt nicht, auf unterster Ebene anzusetzen! (WSGI)
Wieso schaust Du Dir nicht dann ein Rahmenwerk an, welches Dir mehr Flexibilität bietet, wie z.B. Flask?
Oder sollte das auch noch zu starr sein, dann nimm eben Werkzeug und baue Dir darauf Dein eigenes Framework bzw. Deine Web-Applikation.
Das wäre der logische Weg, den Du beschreiten solltest. Auf unterster Ebene anzusetzen ist wenig ratsam, da man ein echter Experte sein muss, um dort fehlerfrei und sicher drauf aufzusetzen. Nicht umsonst haben wir hier nur einen "Knight of the WSGI" im Forum
Als letztes ist mir absolut unklar, wieso es dann auf PHP hinaus laufen muss! Selbst mit einer universellen WSGI-Lib wie Werkzeug hast Du doch mit Python eine wesentlich angenehmere Umgebung zum Entwickeln von Web-Applikationen! Dazu kannst Du Dir eben je nach Bedarf sinnvolle Libs, wie Jinja2 fürs Templating, WTForms für Formvalidierung usw an Bord holen. Was bietet denn bitte schön PHP da mehr bzw. komfortableres? Auch in PHP sollte man imho auf ein Framework zurückgreifen, es sein denn, man weiß was man tut.
(Anhand der vielen schrottigen PHP-Applikationen sieht man, dass das augenscheunlich viele nicht wissen)
Was ich mir denken kann wäre natürlich noch, dass Du in Python einfach nicht fit genug bist, um aus gegebener Doku zu Projekten die nötigen Erkenntnisse für das eigene Problem zu ziehen. Das soll jetzt keine Beleidigung sein, sondern wirklich eine plausible Vermutung. Denn Tutorials zeigen einem natürlich immer nur kleinere Sachen; Du wirst kein Tutorial a la "Implementierung einer kompletten Foren-Software mit Django" finden Insofern muss man die präsentierten Konzepte verstehen und auf das eigene Projekt übertragen können. Je kleiner die Snippets sind, desto schwieriger fällt einem da oftmals die Einordnung in die eigene Problematik. Speziell von Django hört man eigentlich immer recht gutes bezüglich der Doku (gilt im übrigen insbesondere auch frü Flask).
Als letzte Alternative hängt sicherlich auch viele davon ab, was Du wirklich für Anforderungen hast. RichClient-GUIs fürs Web werden heutzutage doch vor allem in JavaScript implementiert. Dazu gabs iirc auch hier im Forum einige Beiträge.
Ich kenne Deine Anforderungen nicht, daher mag es schon sein, dass Django zu starr und unflexibel für Dich ist. Dann ist die Konsequenz aber bestimmt nicht, auf unterster Ebene anzusetzen! (WSGI)
Wieso schaust Du Dir nicht dann ein Rahmenwerk an, welches Dir mehr Flexibilität bietet, wie z.B. Flask?
Oder sollte das auch noch zu starr sein, dann nimm eben Werkzeug und baue Dir darauf Dein eigenes Framework bzw. Deine Web-Applikation.
Das wäre der logische Weg, den Du beschreiten solltest. Auf unterster Ebene anzusetzen ist wenig ratsam, da man ein echter Experte sein muss, um dort fehlerfrei und sicher drauf aufzusetzen. Nicht umsonst haben wir hier nur einen "Knight of the WSGI" im Forum
Als letztes ist mir absolut unklar, wieso es dann auf PHP hinaus laufen muss! Selbst mit einer universellen WSGI-Lib wie Werkzeug hast Du doch mit Python eine wesentlich angenehmere Umgebung zum Entwickeln von Web-Applikationen! Dazu kannst Du Dir eben je nach Bedarf sinnvolle Libs, wie Jinja2 fürs Templating, WTForms für Formvalidierung usw an Bord holen. Was bietet denn bitte schön PHP da mehr bzw. komfortableres? Auch in PHP sollte man imho auf ein Framework zurückgreifen, es sein denn, man weiß was man tut.
(Anhand der vielen schrottigen PHP-Applikationen sieht man, dass das augenscheunlich viele nicht wissen)
Was ich mir denken kann wäre natürlich noch, dass Du in Python einfach nicht fit genug bist, um aus gegebener Doku zu Projekten die nötigen Erkenntnisse für das eigene Problem zu ziehen. Das soll jetzt keine Beleidigung sein, sondern wirklich eine plausible Vermutung. Denn Tutorials zeigen einem natürlich immer nur kleinere Sachen; Du wirst kein Tutorial a la "Implementierung einer kompletten Foren-Software mit Django" finden
Insofern muss man die präsentierten Konzepte verstehen und auf das eigene Projekt übertragen können. Je kleiner die Snippets sind, desto schwieriger fällt einem da oftmals die Einordnung in die eigene Problematik. Speziell von Django hört man eigentlich immer recht gutes bezüglich der Doku (gilt im übrigen insbesondere auch frü Flask).Als letzte Alternative hängt sicherlich auch viele davon ab, was Du wirklich für Anforderungen hast. RichClient-GUIs fürs Web werden heutzutage doch vor allem in JavaScript implementiert. Dazu gabs iirc auch hier im Forum einige Beiträge.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
deets
Die Admin-Seiten sind dir wichtig, aber weil sie nicht machen, was du willst, musst du *alles* selbstmachen? Das ist doch totaler Unfug. Frameworks wie TurboGears und andere (Django inklusive) stellen eine Menge Dinge zur Verfuegung, um mit Sieben-Meilen-Stiefeln zu laufen, statt Babyschritte selbst zu machen. HTTP-Spezifika, URL-Raueme, RESTful Interfaces, konsequente Unicode-Behandlung, File-Uploads , Sessions, Authentifikation und Authorization und was weiss ich noch alles. WSGI (das als Komponentenschnittstelle top ist) hat nichts von alldem. Und PHP auch nicht, zumindest das letzte mal als ich damit gearbeitet habe..torres hat geschrieben:Also django hab ich mir nun soweit angeschaut und werde es leider nicht weiter verfolgen.
Das Admin Tool ist fuer meine Beduerfnisse unzureichend und ich habe keine
gute Dokumentation zur Erweiterung gefunden, von Kleinigkeiten abgesehen. Da aber
das Admin-Tool sehr wichtig fuer mich ist, gebe ich also auf. (was ich echt so schade finde)
Ohnehin beziehen sich die ganzen Tutorial alle nur auf solche kleinen Mini-Apps und gehen nicht
besonders tief (und sind alle irgendwie immer die gleichen Beispiele?!)... Und nur mit dem djangobuch stehe ich dann eben recht bald da und komme nicht
weiter, bin eben kein Einstein.
Jetzt gehe ich davon aus, dass die anderen Webframeworks auch nicht gerade besser sind und
schaue mir wsgi an, um es eben doch zu Fuss zu machen...
Hallo Hyperion,
Einmal tue ich mich schwer, mein DB-Konzept in die models.py zu bringen.
ein UNIQUE KEY (bla, foo) muss ich mit einem unique_together in einem class Meta
unterbringen, wobei sich mir voellig entzieht, warum ich das nicht direkt in die Klasse
schreiben kann. Bis da mal alles zusammengesucht ist... Dann hab ich python manage.py inspectdb
gefunden, aber das nimmt solche Sachen nicht mit.
Es ist um vieles einfacher, die DB selbst zuerstellen, wie ich finde.
Im djangobook, ist alles bis zum Abschnitt "Custom ModelAdmin classes" schon in den ganzen Tutorials geschrieben gewesen und schon umgesetzt; und das was dann kommt: schnalle ich nicht :-/ (http://www.djangobook.com/en/2.0/chapter06/)
Ich hab das schon bewundert, dass dann irgendwann, trotz vielem Suchen und Verzweifeln irgendwann ein Admin-Web verfuegbar war, fuer das ich mir mit php drei Tage die Finger wundgetippt haette. Aber dann geht es eben nicht weiter. Meine Anforderungen sind nicht so
gewaltig, ich habe ein paar Tabellen, die alle aneinanderhaengen und nicht alle mit mysql-mittel
sauber gehalten werden koennen. Wenn ich das Admintool nehmen wuerde, muesste ich zum Beispiel irgendwann an ellenlangen Listen verzweifeln, die ich vor dem Editieren erstmal durchsuchen muesste... Ja, und um das weiter umzusetzen, helfen mir die Dokus eben nicht weiter und ja: das wird sicher nicht an den Dokus liegen, sondern an mir? Dann kommen immer Hinweise auf javascript aber das ist doch nicht notwenig fuer ein olles Form, das sich anhand von einer ersten Auswahl seine Inhalte zusammensetzt.
hm, gehe jetzt erstmal Bilderrahmen zimmer...
Viele Gruesse,
Torres
das mag schon mit ein Grund sein: ich hab nur in Ansaetzen von Objektorientierter Programmierung Ahnung (also eigentlich keine), und es faellt mir sehr schwer, da umzudenken und das alles zu begreifen.Hyperion hat geschrieben: Was ich mir denken kann wäre natürlich noch, dass Du in Python einfach nicht fit genug bist, um aus gegebener Doku zu Projekten die nötigen Erkenntnisse für das eigene Problem zu ziehen. Das soll jetzt keine Beleidigung sein, sondern wirklich eine plausible Vermutung.
Einmal tue ich mich schwer, mein DB-Konzept in die models.py zu bringen.
ein UNIQUE KEY (bla, foo) muss ich mit einem unique_together in einem class Meta
unterbringen, wobei sich mir voellig entzieht, warum ich das nicht direkt in die Klasse
schreiben kann. Bis da mal alles zusammengesucht ist... Dann hab ich python manage.py inspectdb
gefunden, aber das nimmt solche Sachen nicht mit.
Es ist um vieles einfacher, die DB selbst zuerstellen, wie ich finde.
Im djangobook, ist alles bis zum Abschnitt "Custom ModelAdmin classes" schon in den ganzen Tutorials geschrieben gewesen und schon umgesetzt; und das was dann kommt: schnalle ich nicht :-/ (http://www.djangobook.com/en/2.0/chapter06/)
Ich hab das schon bewundert, dass dann irgendwann, trotz vielem Suchen und Verzweifeln irgendwann ein Admin-Web verfuegbar war, fuer das ich mir mit php drei Tage die Finger wundgetippt haette. Aber dann geht es eben nicht weiter. Meine Anforderungen sind nicht so
gewaltig, ich habe ein paar Tabellen, die alle aneinanderhaengen und nicht alle mit mysql-mittel
sauber gehalten werden koennen. Wenn ich das Admintool nehmen wuerde, muesste ich zum Beispiel irgendwann an ellenlangen Listen verzweifeln, die ich vor dem Editieren erstmal durchsuchen muesste... Ja, und um das weiter umzusetzen, helfen mir die Dokus eben nicht weiter und ja: das wird sicher nicht an den Dokus liegen, sondern an mir? Dann kommen immer Hinweise auf javascript aber das ist doch nicht notwenig fuer ein olles Form, das sich anhand von einer ersten Auswahl seine Inhalte zusammensetzt.
hm, gehe jetzt erstmal Bilderrahmen zimmer...
Viele Gruesse,
Torres
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hm... also "nicht sauber halten" klingt schon mal verdächtig nach Designfehler! Vielleicht solltest Du hier mal in einem Thread Dein Modell und Deine Intention beschreiben? Evtl. ist Dein DB-Entwurf per se schon schlecht; klar dass es dann zu Problemen kommen kann bei Django, welches sicherlich eine normalisierte DB-Struktur zu schätzen weiß.
Und wenig Erfahrung ist ja nicht schlimm - OOP lernt man imho nicht ausschließlich theoretisch. Wenn Du doch ein Projekt hast, welches Dich dazu motiviert das zu erlernen, dann beiß Dich da doch rein. Mal ehrlich: Mit einem prozeduralem PHP-CGI Ansatz wirst Du Deinen Horizont nicht erweitern
Hier im Forum gibts doch genügend Django versierte Leute; da sollte es doch möglich sein, die unverständlichen Fragen zu klären
Und wenig Erfahrung ist ja nicht schlimm - OOP lernt man imho nicht ausschließlich theoretisch. Wenn Du doch ein Projekt hast, welches Dich dazu motiviert das zu erlernen, dann beiß Dich da doch rein. Mal ehrlich: Mit einem prozeduralem PHP-CGI Ansatz wirst Du Deinen Horizont nicht erweitern
Hier im Forum gibts doch genügend Django versierte Leute; da sollte es doch möglich sein, die unverständlichen Fragen zu klären
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
noisefloor
- User
- Beiträge: 4179
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
@torres: Bis jetzt hast du ja unsere anderen / alternativen Vorschläge ignoriert... Das du mit Django nicht klar kommst ist ja das eine, aber rohes WSGI ist definitiv auch keine Lösung (zur Abschreckung kannst du ja mal die Spez lesen oder ein bisschen hier stöbern.
Echte Alternativen für Webapplikationen wären z.B. Bottle, Flask oder Werkzeug. Letzteres geht schon ein bisschen Richtung "low-level" (wurde ja bereits gesagt). Übrigens sind Flask und Werkzeug ziemlich ausführlich dokumentiert.
Für die DB-Anbindung kannst du z.B. SQLAlchemy nehmen - das ist ja DIE SQL-Waffe schlechthin unter Python. Und die Doku ist mit knapp 200 Seiten A4 auch recht umfangreich. Oder rohes SQL, immerhin gibt es eine DB-API für Python, an die sich die meisten Python-RDBMS-Module halten.
An dieser Stelle passt auch ein Zitat von mitsuhiko (aka "Knight of the WSGI") recht gut:
Werkzeug + Jinja2 + SQLAlchemy = Gold
(bezogen auf Python-basierte Webanwendungen).
Gruß, noisefloor
@torres: Bis jetzt hast du ja unsere anderen / alternativen Vorschläge ignoriert... Das du mit Django nicht klar kommst ist ja das eine, aber rohes WSGI ist definitiv auch keine Lösung (zur Abschreckung kannst du ja mal die Spez lesen oder ein bisschen hier stöbern.
Echte Alternativen für Webapplikationen wären z.B. Bottle, Flask oder Werkzeug. Letzteres geht schon ein bisschen Richtung "low-level" (wurde ja bereits gesagt). Übrigens sind Flask und Werkzeug ziemlich ausführlich dokumentiert.
Für die DB-Anbindung kannst du z.B. SQLAlchemy nehmen - das ist ja DIE SQL-Waffe schlechthin unter Python. Und die Doku ist mit knapp 200 Seiten A4 auch recht umfangreich.
Oder rohes SQL, immerhin gibt es eine DB-API für Python, an die sich die meisten Python-RDBMS-Module halten.An dieser Stelle passt auch ein Zitat von mitsuhiko (aka "Knight of the WSGI") recht gut:
Werkzeug + Jinja2 + SQLAlchemy = Gold
(bezogen auf Python-basierte Webanwendungen).
Gruß, noisefloor
Da kann ich Hyperion nur zu stimmen, deine Beschreibung klingt sehr verdächtig nach einem schlechten DB-Entwurf. In diesem Fall kann dir auch das beste Framework nicht weiterhelfen, da solltest du zuerst ein mal dein Datenmodell überarbeiten.
Am besten stellst du uns das aktuelle zur Verfügung, bevor wir hier weiter ins Blaue schießen
Am besten stellst du uns das aktuelle zur Verfügung, bevor wir hier weiter ins Blaue schießen
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
Deine Schwierigkeiten mit Django kommen meiner Meinung nach daher, dass weder dein Konzept für die Datenbank noch dasjenige für die zu erstellende Software in Ordnung sind. Wenn dazu dann noch das von dir angedeutete gedankliche Problem mit dem Verständnis des OOP-Konzeptes kommt, dann solltest du wirklich einen Schritt zurückgehen.torres hat geschrieben:Meine Anforderungen sind nicht so
gewaltig, ich habe ein paar Tabellen, die alle aneinanderhaengen und nicht alle mit mysql-mittel
sauber gehalten werden koennen. Wenn ich das Admintool nehmen wuerde, muesste ich zum Beispiel irgendwann an ellenlangen Listen verzweifeln, die ich vor dem Editieren erstmal durchsuchen muesste...
Bei der Verwendung des Admin-Tools musst du dir zumindest eines klar machen: Das Admin-Tool ist eine generische Applikation in Django (die nicht für den Enduser gedacht ist). Dein eigentliches Programm musst du dir schon selber schreiben.
Hallo,
wie poste ich mein DB Konzept hier genau? Die Sql-Statements zum erstellen der DB plus einiger Erklaerungen posten? Oder als Bild?
(ich habe tatsaechlich in meinem aktuell verwendeten ein konzeptionelles Problem drin, was ja u.a. auch der Grund fuer ein Redesign ist.
Viele Gruesse,
Torres
wie poste ich mein DB Konzept hier genau? Die Sql-Statements zum erstellen der DB plus einiger Erklaerungen posten? Oder als Bild?
(ich habe tatsaechlich in meinem aktuell verwendeten ein konzeptionelles Problem drin, was ja u.a. auch der Grund fuer ein Redesign ist.
Viele Gruesse,
Torres
Ich würde doch mal sagen, poste lauffähigen Code.torres hat geschrieben:wie poste ich mein DB Konzept hier genau? Die Sql-Statements zum erstellen der DB plus einiger Erklaerungen posten? Oder als Bild?
-
BlackJack
@snafu: Der lauffähige Code zur DB ist doch momentan noch in PHP. Und ein DB-Entwurf ist ja grundsätzlich auch erst einmal unabhängig von der Programmiersprache. Ich denke das Datenbankmodell und eine Erklärung in Prosa soweit das aus dem Entwurf nicht klar wird, reicht aus.
Hallo,
hier waeren mal ein Bild, Prosa und Statements: http://www.ommeluse.de/.data/
(hab mir gedacht, dass das zu viele Daten fuer hier waeren)
Viele Gruesse,
Torres
hier waeren mal ein Bild, Prosa und Statements: http://www.ommeluse.de/.data/
(hab mir gedacht, dass das zu viele Daten fuer hier waeren)
Viele Gruesse,
Torres
-
BlackJack
@torres: Die beiden Tabellen `info` und `url` verstehe ich nicht. Da weichst Du in der grafischen Notation auch vom Rest ab. Was bedeuten `ziel` und `selbst`? Warum verweisen in `url` beide auf `pano`? Was sind da die Rollen der Verbindungen? Und Zusatzinformationen könntest Du doch später auch noch in zusätzlichen Tabellen unterbringen.
Und noch etwas zu den Verbindungen: Ich würde erst einmal redundante Wege vermeiden, solange nicht klar ist, dass dadurch Leistungsprobleme entstehen. Und da bin ich immer recht konservativ -- soll heissen, solange die O-Komplexität in Ordnung ist, gibt es keine Probleme mit der Leistung bis man dass tatsächlich durch Messungen belegen kann. `info.ziel` ist zum Beispiel redundant, weil man da auch über `info.selbst.objekt` hin kommt. Genau so `alt.objekt` was man auch über `alt.pano.objekt` erreicht.
Und noch etwas zu den Verbindungen: Ich würde erst einmal redundante Wege vermeiden, solange nicht klar ist, dass dadurch Leistungsprobleme entstehen. Und da bin ich immer recht konservativ -- soll heissen, solange die O-Komplexität in Ordnung ist, gibt es keine Probleme mit der Leistung bis man dass tatsächlich durch Messungen belegen kann. `info.ziel` ist zum Beispiel redundant, weil man da auch über `info.selbst.objekt` hin kommt. Genau so `alt.objekt` was man auch über `alt.pano.objekt` erreicht.