SQLite Datentyp TEXT, SQLite Engine Handling (Kernel) DB-Struktur, Verwaltung, Spielzeugdatenbank?

  • VB.NET
  • .NET (FX) 3.0–3.5

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von us4711.

    SQLite Datentyp TEXT, SQLite Engine Handling (Kernel) DB-Struktur, Verwaltung, Spielzeugdatenbank?

    Also ich habe jetzt schon sehr viel gegoogelt und auch gelesen. Selbstverständlich auch direkt bei der englischen Seite von SQLite. Jetzt habe ich eine Frage über die Hintergrundverwaltung von SQLite. Dessen Engine - das Handling der Database - Hintergrundverhalten. Eigentlich folgen jetzt mehrere Fragen...

    Begründung oder Herleitung:
    Ich stehe vor der Entscheidung eine Access DB oder eine SQLite DB zuverwenden. Angefangen habe ich jetzt bei meinem Projekt mit einer SQLite Datenbank. Und es klappt auch soweit. Was mir daran gefällt ist die schöne kleine kompakte Größe der, ich sag jetzt mal Mini-DB - die aber dennoch alle Vozüge einer relationalen Datenbank hat.

    Meine Bedenken bei SQLite:
    Zum einen verstehe ich nicht wie es SQLite macht, alles als TEXT zu behandeln. Es gibt scheinbar keine Textbegrenzung. Sowie CHAR(20). Sondern je nachdem was ich da für einen Text INSERT'e, wird das Feld entsprechend größer oder kleiner.

    Die physikalischen Grenzen von SQLite habe ich schon nachgelesen. Die sind ja schon beachtlich. Und reichen auch theoretisch für alle meine Projekte aus. Auch bei Abertausenden Datensätzen. Was so die Größenordnung bei mir sein wird.

    Relationale Datenbank Vorzüge:
    Bei herkömlichen SQL Datenbanken ist ja das bedingt durch den exakten Aufbau einer Tabelle (SMALLINT (2Byte) + FLOAT (4Byte) und CHAR(xBytes) etc.) - sehr genau strukturiert. Da werden entsprechende Blöcke angelegt, da geht alles ganz fix, was das Hintegrundhandling der DB betrifft, wenn eine Abfrage gestellt wird. Dahinter verbirgt sich also meine Frage: "Wie sieht es mit der Performance einer mit Datensätzen aufgeblasenen SQLite DB aus?" - unter Betracht dessen dass TEXT Felder mal so mal so mal so sind!

    Was mich jetzt (noch) stört an SQLite:
    Ich kann nicht genau im voraus berechnen wie die Datenbankgröße meiner Datensätze bei exakt definierten Datensätzen sein wird. Während ich bei Access oder MS-SQL oder anderen großen Datenbanken, genau weiß wieviele Bytes "Ein Datensatz" verbraucht, gibt es hierzu für SQLite nix hilfreiches!

    Daher auch meine Frage:
    Ist SQLite eher eine Spielzeug Datenbank? Sollte man eher auf eine andere nicht so abgespeckte Datenbank zurückgreifen, falls man nicht nur ein Spielzeugprogramm erstellen möchte? Beispielsweise MySQL, oder Access?

    Gemacht habe ich schon sehr viel mit Datenbanken. Aber meistens MySQL. Ziel meiner jetzigen Anwendung ist eine Multiuser (Netzwerk) Anwendung (etwa 10 Personen werden diese gleichzeitig bedienen), mit Projektinformationen. Es wird letztlich ein recht einfaches aber sehr Informatives System werden. So etwa mit 5 Tabellen. Einfach halt soviel, dass ich auf jedenfall mit einer Datenbank arbeiten will/muss, aber bestimmt keine recht professionelle DB erforderlich ist.

    Was mir besonders an SQLite gefällt:
    Bombastisch geil finde ich, dass meine Anwendung dann diese Datenbank einfach mit der Executable kopiert werden muss (+ "System.Data.SQLite.dll") - und schon läuft das ganze ohne jede Aufwendung Installation von MySQL oder einem ODBC Treiber etc.
    Also bis jetzt ist nix neues dabei. Vorallem ob es irrelevant ist oder nicht, dass tut hier gar nix zur Sache!

    --- Ja ich vermute auch das SQLite doch sehr stabil ist. Wird wirklich in vielen weltweit bekannten Tools verwendet. Dennoch bin ich sehr an mehr Details interessiert. Sind denn berufliche Datenbankadministratoren hier unterwegs?

    --- Firebird? okay, dass werde ich bei Gelegenheit wirklich auch mal rechergieren.
    Aber jetzt geht es mir primär mal um Feinheiten zu SQLite... :whistling: