SQLite Anfrageergebnis bezüglich der gesamten Tabelle

  • 10 Antworten
  • Letztes Antwortdatum
D

Der Nat

Neues Mitglied
0
Hallo zusammen,

ich beschäftige mich gerade mit SQLite und habe dazu eine Frage.
Ein query liefert mir doch einen cursor, der sämtliche Zeilen enthält, in denen der key mit meiner where-klausel übereinstimmt.
Daher kann ich mit getCount() heraufinden, ob ein gesuchter Datensatz existiert. Liefert diese Methode mir 0, ist das nicht der Fall. Richtig soweit?

Ich brauche nun aber auch eine Möglichkeit, herauszufinden, in der wievielten Zeile bezüglich der gesamten Tabelle mein erster Treffer liegt. Wie könnte ich das bewerkstelligen?
 
Hallo Nat

Jeder Datensatz hat ja meist einen
Code:
INTEGER PRIMARY KEY AUTOINCREMENT
dieser INTEGER wäre dann deine Zeilennummer.
Allerdings wäre diese falsch wenn schon mal ein Datensatz gelöscht wurde.

Um an die echte Zeilennummer zu kommen müsstest du alle Datensätze abfragen und dann mit einer schleife nach deinem Wert suchen.

Aber ich verstehe den Sinn des ganzen noch nicht so ganz :confused:

Gruß
derjens
 
  • Danke
Reaktionen: Der Nat
Hallo Jens,

meine Datenbank umfasst Datensätze, denen jeweils ein Datum zugeordnet ist.
Dieses Datum ist momentan mein PRIMERY KEY.
Um meine Datenbank nun schmall zu halten, möchte ich Datensätze, deren Datum in der Vergangenheit liegt löschen. Da ich davon ausgehe, dass die Datensätze stehts einfach untenangefügt werden, bleibt die Anordnung der Daten relativ zu einander korrekt. (Stimmt das überhaupt?)
Meine Idee war nun eben: Zeilennummer des ersten Treffers bestimmen. Dann kann ich alle davor liegenden Datensätze löschen und weiß zusätzlich gleich noch, wieviel ich nachladen muss um eine konstante Anzahl von Datensätzen zu haben.

An der Schleifenvariante arbeite ich gerade. Hatte aber gehofft, das ginge irgendwie eleganter...
 
Ja, die Daten werden immer am Ende angefügt.

Ich würde aber an deiner stelle ne abfrage über die Datensätze machen die du löschen willst und diese dann löschen.
Ich würde aber auch NICHT auf die Idee kommen das Datum als PRIMARY KEY zu definieren ;)

Gruß
derjens
 
derjens schrieb:
Ich würde aber auch NICHT auf die Idee kommen das Datum als PRIMARY KEY zu definieren ;)

Das ist das schöne an neuer Materie, man macht Dinge von dennen man nachher weiß, dass man sie besser hätte lassen sollen. ;)

Mal im Ernst: Was spricht dagegen?
 
Weiß nicht genau ob da grundsätzlich was gegen spricht aber ich würde es nicht machen.

Mit deiner Methode muss du den PRIMARY KEY immer manuell setzen und auch aufpassen das du ihn nicht doppelt vergibst. Mit nem
INTEGER PRIMARY KEY AUTOINCREMENT brauchst du dir darüber keine Gedanken machen.

In deinem Fall wäre es vielleicht sogar besser gewesen da du dann mit der ID die Zeilennummer hast ;)

Kannst du denn ein query machen in dem alle Datensätze sind die du löschen willst?
 
Der Nat schrieb:
Mal im Ernst: Was spricht dagegen?

1.) Weil es mehrere Datenstätze mit dem selben Datum geben könnte. Wenn nicht jetzt, dann vielleicht später.

2.) Weil ein Datum als Foreign Key zu Schwierigkeiten führen kann (nicht zuletzt wegen 3.)

3.) Weil Datumsfelder in SQLite semantisch unscharf (bzw eigentlich garnicht) definiert sind. Mit andern Worten: In welchem Format wird das Datum gepeichert? (Hab da schon ne menge Spaß bei Datenmigrationen gehabt).

4.) Sowas tut man nicht :D (Ich will jetzt nicht mit Datenbanktheorie kommen, aber in gewisser Weise ist der Primary Key der Datensatz. Sind deine Daten das Datum? Wohl eher nicht)
 
  • Danke
Reaktionen: Der Nat
Ein Datum wird doch eh immer als long (bzw. In SQLite als int) abgelegt. Von daher geht das als PK schon. Man muss ihn halt immer manuell setzen und Du kannst kein auto increment nutzen. Ich würde es aber trotzdem auch nicht machen.
 
Wie schon gesagt wurde, solltest du lieber ein Integer Autoincrement Feld als Key nutzen.

Und zum löschen brauchst du vorher doch nichts abfragen.

DELETE FROM foo WHERE datum < X.Y
 
TheEvilOne schrieb:
Ein Datum wird doch eh immer als long (bzw. In SQLite als int) abgelegt.

Glaubst du. Ich hab da schon doubles (julian date) und ISO codierte Datumsangaben in Textform gefunden.
 
Da ich ja auch einen halbwegs schönen Pragrammierstil umsetzen möchte und das mit dem Datum und dessen Einzigartigkeit tatsächlich so eine Sache ist, habe ich auf Integer mit Autoincrement umgestellt. ;)

Mein ursprüngliches Problem habe ich nun auch über eine Schleife gelöst und funktioniert soweit auch einwandfrei.

Bevor der Thread nun zur Ruhe gebettet wird noch eine Frage:
Hat man in Eclipse eine Möglichkeit sich die SQLite-Tabellen zu Debugzwecken anzusehen?

Der ursprüngliche Beitrag von 18:25 Uhr wurde um 19:07 Uhr ergänzt:

Fall hat sich erledigt. Hab den Questoid SQLite Browser gefunden. Danke an alle helfenden. :)
 
Zurück
Oben Unten