SQLite Anwendung lokal, Ablage Daten Homepage

[gerold]

Hallo genders!

Dir sollte klar sein, dass, wenn du kein Programm auf dem Server laufen hast (wie z.B. PostgreSQL oder ein CGI-Programm) welches die Daten aus der DB ausliest und gefiltert zum Client schickt, dann musst du jedes mal die ganze Datenbank übertragen. Auch wenn du nur ein paar Daten brauchst.

Das sehe ich mir dann mal an, wenn die DB ein paar MB groß geworden ist.

Und das ist der Grund, weshalb wir dir mit all unserer Kraft sagen wollten, dass du ein Programm auf dem Server brauchst. Sei es ein PostgreSQL-Serverprogram, ein MySQL-Serverprogramm, oder ein Serverprogramm das die SQLite-Datenbank verwendet. Du brauchst ein Programm auf dem SERVER.

Wenn du das nicht beherzigst, dann wirst du für jede Kleinigkeit immer die ganze Datenbankdatei übertragen müssen. Das ist auch bei kleinen Datenmengen nicht wirklich brauchbar.

mfg
Gerold

[amiganer68]

Hallo!

Jetzt möchte ich mich auch mal kurz mit einem Gedanken dazu melden:

Wenn ich richtig verstehe, was Du willst, dann solltest Du nicht SQLite verwenden, sondern Dir mal SQLAlchemy ansehen. Du brauchst dann nur einen WEB-Hoster, der dich auch von außen auf die dortige Datenbank zugreifen läßt. In der Regel (wurde schon gesagt) geht das ab einem vServer und (leider) nicht auf einem normalem Webspace.
Hier würdest Du dann SQL für den ZUgriff erzeugen und die Daten in der Datenbank auf dem Webspace ablegen.

Christian

[/me]

Wenn ich richtig verstehe, was Du willst, dann solltest Du nicht SQLite verwenden, sondern Dir mal SQLAlchemy ansehen. Du brauchst dann nur einen WEB-Hoster, der dich auch von außen auf die dortige Datenbank zugreifen läßt.

SQLAlchemy und SQLite sind ganz unterschiedliche Dinge.

In diesem Kontext ist SQLAlchemy nur der objektorientierte Zucker für den Zugriff. Wenn eine Datenbank auf dem Server läuft und nach außen hin offen ist, dann kannst du auch ohne den SQLAlchemy-Overhead darauf zugreifen.

[DasIch]

In diesem Kontext ist SQLAlchemy nur der objektorientierte Zucker für den Zugriff.

SQLAlchemy hat ein ORM, dass heisst dass du es benutzen musst.

[/me]

SQLAlchemy hat ein ORM, [...]

Das würde ich anders ausdrücken: SQLAlchemy ist ein ORM.

[DasIch]

Das würde ich anders ausdrücken: SQLAlchemy ist ein ORM.

Was ich mit meinem Satz sagen wollte, ist dass genau dass nicht stimmt. Du solltest mal einen Blick auf die Expression Language werfen auf der das ORM aufbaut.

Ich denke man sollte sich die Expression Language zumindest einmal angesehen haben bevor man das ORM benutzt.

[/me]

Das würde ich anders ausdrücken: SQLAlchemy ist ein ORM.

Was ich mit meinem Satz sagen wollte, ist dass genau dass nicht stimmt. Du solltest mal einen Blick auf die Expression Language werfen auf der das ORM aufbaut

Entweder reden wir aneinander vorbei oder wir sind tatsächlich einfach unterschiedlicher Meinung.

Möchtest du mir hier ernsthaft sagen ich solle meine Datenbankabfragen via Python in einer merkwürdigen Expression Language modellieren um dann auch noch auf das eigentliche ORM zu verzichten? Das kann ich doch nur falsch verstanden haben, oder?

Das Schlimmste an ORMs ist für mich genau diese Art und Weise wie dort Queries definiert werden. Für simple Sachen ist das ganz nett, aber ich habe hier SQL-Statements über mehrere Bildschirmseiten mit einer zum Teil zweistelligen Tabellenanzahl. So etwas will man nicht mehr über ein ORM modellieren und deshalb verwende ich dafür klassisches SQL via cx_oracle oder psycopg2.

Ich brauche keinen zusätzlichen Layer dazwischen und genau das ist das worauf ich zuletzt hinaus wollte. Ursprünglich ging es mir nur darum zu erklären, dass man nicht SQLite durch SQLAlchemy austauschen kann weil es sich dabei auf der einen Seite um eine Server- und auf der anderen um eine Client-Komponenten handelt.

[DasIch]

Möchtest du mir hier ernsthaft sagen ich solle meine Datenbankabfragen via Python in einer merkwürdigen Expression Language modellieren um dann auch noch auf das eigentliche ORM zu verzichten? Das kann ich doch nur falsch verstanden haben, oder?

Auf die Weise hat man mehr Kontrolle über dass erzeugte SQL als beim ORM und ist unabhängig von der Datenbank. Die Lösung ist nicht so abwegig.

[amiganer68]

Wenn ich richtig verstehe, was Du willst, dann solltest Du nicht SQLite verwenden, sondern Dir mal SQLAlchemy ansehen. Du brauchst dann nur einen WEB-Hoster, der dich auch von außen auf die dortige Datenbank zugreifen läßt.

SQLAlchemy und SQLite sind ganz unterschiedliche Dinge.

In diesem Kontext ist SQLAlchemy nur der objektorientierte Zucker für den Zugriff. Wenn eine Datenbank auf dem Server läuft und nach außen hin offen ist, dann kannst du auch ohne den SQLAlchemy-Overhead darauf zugreifen.

Das beide nicht identisch sind, war mir klar. Doch kam ich, als ich versucht habe, hinter das ursprüngliche Problem zu kommen auf folgendem Schluss: SQLite wird mit SQL gefüttert um Daten zu speichern/lesen. Jetzt möchte der Kollege hier in seiner ursprünglichen Frage diese Daten, die bei SQLite in einer Datei gespeichert werden, auf einem Webspace auslagern. Da auf dem Webspace meistens schon eine Datenbank läuft, wäre hier SQLAlchemy als bindeglied nicht verkehrt. Und evtl. kann er auch noch mit nur wenigen SQL-Kenntnissen diese Sache abstrahieren.
Darum mein Beitrag zum Thema.

Christian

[ms4py]

Das beide nicht identisch sind, war mir klar. Doch kam ich, als ich versucht habe, hinter das ursprüngliche Problem zu kommen auf folgendem Schluss: SQLite wird mit SQL gefüttert um Daten zu speichern/lesen. Jetzt möchte der Kollege hier in seiner ursprünglichen Frage diese Daten, die bei SQLite in einer Datei gespeichert werden, auf einem Webspace auslagern. Da auf dem Webspace meistens schon eine Datenbank läuft, wäre hier SQLAlchemy als bindeglied nicht verkehrt. Und evtl. kann er auch noch mit nur wenigen SQL-Kenntnissen diese Sache abstrahieren.
Darum mein Beitrag zum Thema.

Christian

Vielleicht liest du dir in Zukunft den gesamten Thread durch, bevor du irgendeinen OffTopic-Kommentar abgibst (der dann sogar noch zu weiteren OffTopic-Diskussionen führt...). Das Problem des OP ist, dass er eben keinen DB-Server auf dem Webspace hat und deshalb irgendeine seltsame Lösung mit Sqlite implementieren will.

[lunar]

@/me: Oh, es steht Dir durchaus frei, auf eine „merkwürdige Expression Language“ zu verzichten, und Deine SQL-Ausdrücke stattdessen mittels Zeichenkettenverknüpfung manuell zusammen zu basteln