Variable Datenbank...

Django, Flask, Bottle, WSGI, CGI…
Antworten
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Frohes neues euch allen...

Ich hab da eine Idee, die mir schon längere Zeit im Kopf herrum schwirrt... Aber man kommt ja zu nix...

Also eine Variable Datenbank um variable Tabellen auf der Homepage zu haben. Die man Filtern und sortieren kann, wie man will. Ein wenig so wie z.B.: http://www.heise.de/preisvergleich/?cat ... x+K#xf_top

Im Grunde das was Django von sich aus bietet: Datenbank Modelle Aufsetzten und automatisch eine Admin Ansicht zu generieren. Nur das man es nicht Programmieren soll, sondern sich irgendwie auf der Webseite zusammen klicken kann.

Also quasi ein zusammen klick baren Django-DB-Model.

Wird natürlich darauf hinaus laufen, das man die Tabellenerzeugung bzw. das Auslesen der "Datenbank" nicht sehr effektiv gestalten kann. Aber perfomance sollte hier nicht all zu wichtig sein.


Anwendungszweck könnte jegliche "Liste" von Dingen auf der eigenen Homepage sein. Praktischer als per Hand HTML-Tabellen zu erzeugen.
Also z.B. meine Lieblingsfilme/Lieblingsmusik. Meine Gartenzwerg-Sammlung oder meine Sammlung von Geschirrspülern mit Technischen Daten oder z.B. meine Lieblings Neuerungen in Python mit Sourcecode-Schnippseln und Links oder sowas in der Art...


Allerdings denke ich nicht, das noch keiner darauf gekommen ist. Kennt also jemand eine Django-App sie sowas kann?


https://github.com/bradleyayers/django-tables2 ist zumindest für die Darstellung der Tabellen Daten schon mal die richtige Richtung. Aber hier muß man halt normale Django-Models programmieren.
Weiter Varianten ist hier: https://www.djangopackages.com/grids/g/tables/ aber IMHO alles für "statischen" Django Models.

Evtl. ist https://github.com/charettes/django-mutant was brauchbares?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mal ein paar Überlegungen, wie das denn aussehen könnte:

* TabellenNamenModel
* SpaltenTypModel (ForeignKey zu TabellenNamenModel)
* ZellenInhaltModel (ForeignKey zu SpaltenTypModel)

Das SpaltenTypModel könnte dann im Prinzip sowas wie ein forms.field sein.
Dazu könnte man eine Liste der Built-in Field classes erstellen und anbieten.

Aber das muß es doch schon geben, oder???

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Ich denke man tut sich mit dem relationalen Datenbank Design einfach schwer damit, etwas flexibles und dynamisches darin abbilden zu wollen. Letztlich kann man alles irgend wie in so einer DB ablegen, aber ob das angenehm und sinnvoll ist, steht auf einem anderen Blatt.

Vermutlich kannst Du das schon erreichen, aber vermutlich wäre es einfach, dafür eine andere Persistenzschicht zu verwenden, wie etwa eine Dokumenten zentrierte DB.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Sicherlich gibt es da bessere Lösungen. Ich denke aber an Otto-Normal-Django-User, die jetzt kein Kompliziertes Setup aufbauen wollen, um eine App für ihre Sammlung zu nutzten...

Wie gesagt, ist schon klar, das es nicht perfomant wird. Aber ich denke es wir ausreichend sein. Zumal man die Ausgabe cachen kann.

Ich hab jedenfall schon öfters mal den Wunsch gehabt, Daten in Tabellen zu "oganisieren". Aber HTML Tabellen, auch mit Markup ist einfach nur ein Krampf, wenn es mehr Zeilen/Spalten wird. Aber eine extra App zu bauen, die genau für den jeweiligen Anwendungsfall die Models bereit hält, ist totaler Overkill.

Ein Beispiel wäre: http://www.jensdiemer.de/de/Bilder/Pentax_Zeitleiste/ ich würde da gern mehr Daten Unterbringen. Aber per Hand? Keine Lust ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Und was ist mit JSON oder XML? Damit müsstest Du zwar selber die Filter- und Query-Möglichkeiten implementieren (ok, es gibt mittlerweile ja durchaus RDBMS mit Support für solche Felder), aber wenn es primär um die Anzeige und nicht um Performance geht, ist das doch ggf. ein gangbarer Weg.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Primär geht es um das einfach einrichten, seiner individuellen Tabelle. Also im Admin sich seine Tabelle zusammen stellen. Aber ja, man könnte die Daten der Tabelle auch in JSON speichern. Mache ich quasi so ähnlich bei https://github.com/jedie/django-dbpreferences Dort werden die Taben einer "forms" als einen Eintrag in der DB gepackt. Wobei ich dort noch nicht auf JSON setzte, sondern auf einen "sicheres" dict, s. https://github.com/jedie/django-dbprefe ... ta_eval.py

Also im Grunde sollte man sich im Admin eine forms zusammen klicken, welches dann eine Spalte in der Tabelle entspricht.
Vielleicht sollte ich mal nach "dynamic forms" suchen...

EDIT: Ah -> https://pypi.python.org/pypi/django-dynamic-forms

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
/me
User
Beiträge: 3555
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

jens hat geschrieben:Aber das muß es doch schon geben, oder???
Vor Jahrzehnten habe ich auf einer AS/400 mit RPG an so etwas gearbeitet und ein Nachfolger davon ist immer noch im Einsatz.

Was du im Endeffekt baust ist ein Generierungstool für Leute die sich ohnehin auskennen. Der "normale" Endanwender ist typischerweise mit dem Begriff "Fremdschlüssel" schon völlig überfordert. Einfaches Zeug, welches man sonst in einer Tabellenkalkulation unterbringen würde, kannst du damit natürlich erstellen.
Antworten