SQL Fragen zu SQLite-Eigenheiten und Volltextsuche

[WilliTheSmith]

Hallo,
für ein kleines Software-Projekt brauche ich eine Datenbank. Meine Wahl viel aus mehreren Gründen auf SQLite. Nachdem ich mich nun etwas in der Dokumentation des Projekts umgeschaut habe, habe ich ein Paar Fragen:

1. Ist es richtig, das ich einen Primärschlüssel nicht "unsigned" machen kann? Gibt es unsigned in SQLite überhaupt?

2. Ist es möglich, Fremdschlüssel standardmäßig aktiviert zu lassen? Nach jedem Verbindungsaufbau erstmal "PRAGMA foreign_keys = ON;" auszuführen ist nämlich etwas nervig.

Und zu guter letzt würde mich noch interessieren, ob jemand von euch Erfahrungen mit der Volltextsuche(FTS3/4) von SQLite hat. Ich habe nämlich eine Tabelle, die etwa 23000 Datensätze enthalten wird und in denen ich über mehrere Spalten (nicht alle) suchen möchte. Die meisten Spalten enthalten nur wenige Wörter, doch eine enthält pro Datensatz etwa 1000 Zeichen. Sollte meines Erachtens kein Problem sein.

Ich frage mich jedoch, ob diese "virtuelle Tabelle" irgendwelche Auswirkungen auf Joins mit echten Tabellen oder andere Select-Anweisungen hat.
Ist sowas wie

SELECT * FROM table WHERE (col BETWEEN 200 AND 300) OR (othercol BETWEEN 700 AND 8000);

ohne großartigen Performanceverlust möglich?
Gibt es andere Nachteile?


Ich freue mich auf eure Antworten und vielleicht auch kleine Erfahrungsberichte.

Gruß

 

[roker002]

Ich würde mal sagen, lies die manuals. http://www.sqlite.org/foreignkeys.html

Wegen unsinged bin ich mir da unschlüssig. Wozu willst du nur unsigned Werte. Du kannst genau so gut signed nehmen.

Fulltext search kannst du auch hier nachlesen
http://www.sqlite.org/fts3.html

Ich würde gerne dir helfen aber mehr nicht. Man sollte als Programmierer auch selbst entscheiden können was man braucht und was nicht!

 

[WilliTheSmith]

Hallo,
die Links kannte ich bereits. Wie ich schrieb, habe ich mich schon intensiv mit der Dokumentation auseinander gesetzt.

Zu unsigned: Es gibt durchaus Anwendungsfälle, in denen ein unsigned int nützlich sein kann. Deswegen wüsste ich es gerne vorher, ob es sowas in SQLite gibt.

Zu den FKs wird kein Wort verloren, ob man sie per default aktivieren kann.

Zu FTS3: Auch hier wird kein Wort dazu verloren, wie sich die Performance von Joins mit normalen Tabellen sowie Abfragen auswirkt.

Gruß

 

[Hancock]

Also, soweit ich das verstanden hab:
Foreign-Keys sind immer standardmäßig deaktiviert. Wenn du eine Kapselklasse für den Verbindugnsaufbau schreibst, ist das Pragma aber kein Problem (oder du baust dir SQLite selber noch mal)
unsigned gibt's nicht und wird dich auch nicht stören (sonst on update Trigger, um negative zahlen zu finden)
Wenn ich fts3 richtig verstehe, ist das "parallel" und sollte daher die Performance von JOINs nicht beeinflussen (INSERTs logischerweise schon).

 

[roker002]

Es steht irgendwo unten, dass es eventuell auch Tage sein können bis der neuer Index für Fulltext neu gebaut wird.

Eine eigene Optiomierung zu nehmen anstatt auf bestehende Technologien zu setzen hat ab und zu vorteile aber auch ein sehr großes Manko. Man kann nie vorraussagen ob die aktuellere Version die eigene Optiomirung übetrieft.

23.000 Datensätze ist, in der Datenbankwelt (tut mir leid das schreiben zu müssen), eine lächerliche Anzahl. Wenn es 23.000.000.000.000 wären, würde Optiomierungen sinn machen. Man kann ruhig mit LIKE arbeiten. Ich würde verstehen wenn die Suche mehrere Sekunden (ab 10 sekunden) dauern sollte. Aber bis zu 3 Sekunden ist es vollkommen OK.

Ich habe schon mit Datenbanken gearbeitet die mit mehreren Milliarden Daten befüllt wurden. Eine Optimierung wäre die Tabelle zu zerteilen und eventuell ein paar Limitierungen drauf setzen um die Suche zu verfeinern.

 

[WilliTheSmith]

Also, soweit ich das verstanden hab:
Foreign-Keys sind immer standardmäßig deaktiviert. Wenn du eine Kapselklasse für den Verbindugnsaufbau schreibst, ist das Pragma aber kein Problem (oder du baust dir SQLite selber noch mal)

Wird wohl auf ersteres hinauslaufen. Wobei ich mir das selber kompilieren nochmal anschauen werde, vielleicht gibt es ja ein USE-Flag. (Arbeite unter Gentoo)

Es steht irgendwo unten, dass es eventuell auch Tage sein können bis der neuer Index für Fulltext neu gebaut wird.

Danke für den Link, hat mir gut weiter geholfen.

23.000 Datensätze ist, in der Datenbankwelt (tut mir leid das schreiben zu müssen), eine lächerliche Anzahl. Wenn es 23.000.000.000.000 wären, würde Optiomierungen sinn machen. Man kann ruhig mit LIKE arbeiten. Ich würde verstehen wenn die Suche mehrere Sekunden (ab 10 sekunden) dauern sollte. Aber bis zu 3 Sekunden ist es vollkommen OK.

Ich habe schon mit Datenbanken gearbeitet die mit mehreren Milliarden Daten befüllt wurden. Eine Optimierung wäre die Tabelle zu zerteilen und eventuell ein paar Limitierungen drauf setzen um die Suche zu verfeinern.

Ich habe auch bereits mit Datenbanken gearbeitet, die Millionen an Datensätzen enthielten. Dabei handelte es sich jedoch um Mysql sowie Postgresql-Datenbanken. Mit SQLite habe ich keine Erfahrung und habe deshalb nochmal nachgefragt.

Mit LIKE möchte ich nicht arbeiten, aus dem einfachem Grund, dass ich gerne eine - vereinfacht gesagt - Google-ähnliche Suche hätte. Auch 3 Sekunden suchen wäre viel zu lang und würde meinen Qualitätsansprüchen (und dem des Anwenders) nicht gerecht werden.

Ich bedanke mich für eure Hilfe.
Gruß