German Interessiert sich hier noch jemand für SQLite?

[berndgoedecke]

Hallo erstmal,
ich bin jetzt seit ca. einem halben Jahr dabei von NSBasic nach B4PPC umzusteigen und fühle mich inzwischen vor allem in dem angenehmen Editor heimisch.
Bei meinem derzeitigen Projekt geht es darum eine Anwendung die ich bereits seit mehr als zwei Jahren in NSBasic geschrieben habe in B4PPC umzusetzen.
(.Net basierte Outlook-inkompatibilitäten nötigten mich dazu)
Meine Beispieldatenbank bezieht sich dabei auf ein Geräteverwaltung, im klinischen Bereich, für ca. 50.000 Datensätze mit 27 Spalten. Anzeige, Suche,Listen- und Logikfilter kann in der NSbasic-Version bereits, allerdings nur auf Textbasis, bearbeitet werden.
Für die nächste Version habe ich mir die Berücksichtigung von Datentypen fest vorgenmmen.
Es würde mich freuen wenn es jemanden im deutschsprachigen B4P-Forum gäbe der ein ähnliches Projekt bearbeitet und mit dem man evtll. zusammen arbeiten könnte.

Viele Grüße

berndgoedecke

 

[Fontanus]

Ja, es gibt noch Jemand...

... der sich auch für SQlite interessiert. Ich habe eine Anwendung, die auf einem MDACIII läuft und auch einige Tausend Datensätze mittlerweile umfaßt. Und das Schönste an der Geschichte ist, daß die Datenbankgröße ca. 450kB beträgt.

Eine geringere Anzahl Datensätze in ACCESS brachten immerhin fast 2 MB zusammen.

Ich bin zwar nicht täglich hier im Forum, aber, wenn sich eine Zusammenarbeit ergibt, kann ich zumindest regelmäßig vorbeischauen.

MfG

Fontanus

 

[berndgoedecke]

Na super!!

Hallo Fontanus,
die Sache mit der Größe der Datenbank relativiert sich wenn mann in großen Datenmengen schnell filtern will. Dazu ist es hilfreich Indizes anzulegen. Ich habe mir angewöhnt alle Spalten zu indizieren, weil ich bis jetzt noch nichts gefunden habe, wie auf die autoindex- Funktion von SQlite zurückgegriffen werden kann.
Sind alle Spalten indiziert ist der Größenunterschied nicht mehr so gewaltig.
Die Geschwindigkeit beim filtern, nach anderen Kriterien außer RowID, steigt aber enorm.
Im Moment schreibe ich gerade an einem Konverter, der als Zwischenstufe ein Tabellenlayout anbietet, dass wie bei CSV-Dateien naturgemäß, aus varchar bzw. Text besteht. Dieses Layout möchte ich dann vor der entgültigen Konvertierung verändern und speichern können, damit man Sortierungen, Größer- und Kleiner-Funktionen etc. sinnvoll im Datenbestand anwenden kann. Ich denke mal in ein bis zwei Wochen sollte er soweit sein, danach kann ich mich dann wieder der PPC Anwendung widmen.
Vielleicht ergibt sich ja noch eine Interesseschnittmenge, die man dann gemeinsam beackern kann.

Viele Grüße

berndgoedecke

 

[Rallig]

Hi ihr beiden,

ihr seit nicht alleine ... ich mache auch mit SQLite rum.
Ich habe mal eine Anwendung kreiert, die mir beim Abnehmen helfen soll. So à la WeightWatchers. Vorher war die Anwendung durch SprintDB realisiert. Die benutzt eine proprietäre DB aber doch schon relational. Nach einem Neuaufsetzen des Systems lief diese dann aber so grottenlangsam, das ich was anderes brauchte. SQLite hat sich gefunden :sign0140: und B4P als Anwendungssystem :sign0188:

Ich haber mich nur nicht angesprochen gefühlt, da meine Datenmenge bei weitem nicht an 50.000 Datensätze (wie ist denn eigentlich die Verteilung auf die einzelnen Tabellen) heranreicht. MyBiggest-Table umfasst jetzt gerade 1200 Einträge. Generell ist da noch nichteinmal ein Index nötig *g* - naja.

Also ich schaue auch oft genug hierherein und beobachte gerne, wie es euch so ergeht

Gruß
Rallig

(P.S. @berndgoedecke Du benutzt für jede Spalte einen Index ? Das klingt mutig )

 

[berndgoedecke]

Hallo Rallig,
das konsequente durchindizieren mag sich mutig anhören und wird auch in der einschlägigen Literatur nicht umbedingt empfohlen, aber bei entsprechnder Datenmenge, hat sich diese Methode bewährt, was die Suche anbelangt.
Bei Änderungen an den Datensätzen rechne ich allerding mit einem größeren Zeitaufwand, weil ich dann erst die betroffene Spalte(n) reindizieren muß. Bei geringen Datenmengen fällt das vermutlich, zeitlich nicht so ins Gewicht.
Toll wäre es wenn jemand herausbekommen könnte, wie das mit dem autoindex funktioniert, so wie es in vielen SQLite-Programmen zur Anwendung kommt. Ich hab schon häufiger die SqLite Hompage durchforstet, aber leider ohne Erfolg.

 

[Rallig]

Nabend,
was meinst Du denn mit AutoIndex ?

 

[berndgoedecke]

NMorgen,
Ich hab hier mal zwei Hardcopies von SQLite3DBManager und vom Firefox PlugIn SQLite-Manager, die den Autoindex, genauso wie z.B SQLite2008Pro, verwenden. Der Autoindex wird vom Programm automatisch erzeugt wenn eine Tabelle nicht indiziert ist. Ich hab' zuerst gedacht es gibt vielleicht irgendeine pragma-Einstellung die dazu führt, habe aber nichts gefunden.

Gruß

berndgoedecke

 

[Rallig]

Hi,

:sign0013: aber irgendwie macht mir diese Sache mit dem AutoIndex jetzt irgendwie keinen Sinn. Die Datenbank darf sich doch nicht aussuchen dürfen, welches Feld sie indiziert, ausser den Primary Key - doch der wird eh schon als Index angelegt ... aber ich denke ich bin da auf einem total falschem Dampfer.

Die Bilder/Screenshots die Du dort erstellt hast, zeigen beide die Northwind.sl3 oder ? Da ist es doch schonmal gut, dass die Indizes identisch sind
Aber die Indizes wurden bei der Konvertierung von northwind.mdb (also Access) nach northwind.sl3 (sqlite) übernommen (allerdings nur die PrimaryKeys so wie es aussieht). Und das Programm, was dies anstellt wäre z.B. dataPro (keine Ahnung, ob das andere Konvertierungsprogramme auch so machen) - Siehe Bild -

Würde mich jetzt also auch interressieren, ob es sowas wie einen AutoIndex gibt (also ausser den PrimaryKey).

 

[Fontanus]

Hallo, Ihr Beiden....

.... glücklicherweise gibt es doch noch ein paar SQLite-Fans. Prima!

Zum Thema Indexierung habe ich mich zu folgender Vorgehensweise entschlossen.

- Alle Felder, nach deren Inhalten regelmäßig gesucht wird, sind indiziert.
- Alle Felder, die Tabellen verknüpfen, sind ebenfalls indiziert.

Alle anderen Felder lasse ich zunächst so wie sie sind. Ergibt sich die Notwendigkeit, kann ich das indizieren nachholen.

Eine andere Frage stellt sich mir in Anbetracht der 27 Tabellenspalten. Sind diese Felder alle in einer Tabelle? Oder wurde die Datenbank normalisiert?

Erst schönen Gruß

Fontanus

 

[berndgoedecke]

Hallo SQLite-Fans,
die Tabelle mit den 27 Spalten stammt aus SAP-PM, sie resultiert aus einer "dynamischen Listausgabe", eine Art CSV-Tabelle, lediglich 6 Felder aus den Partnerrollen (Hersteller,Lieferant und Servicefirma incl. Nummer) sind hinzugelinkt, da an die Partnerrollen schlecht heranzukommen ist.

Zum Thema Primary-Key muß ich sagen, das der, soweit ich das bisher gelesene richtig interpretiere, nur aus Kompatibilitätsgründen in SQLite integriert wurde.
Hier die Passage aus der SQLite Dokumentation:

Specifying a PRIMARY KEY normally just creates a UNIQUE index on the corresponding columns. However, if primary key is on a single column that has datatype INTEGER, then that column is used internally as the actual key of the B-Tree for the table. This means that the column may only hold unique integer values. (Except for this one case, SQLite ignores the datatype specification of columns and allows any kind of data to be put in a column regardless of its declared datatype.) If a table does not have an INTEGER PRIMARY KEY column, then the B-Tree key will be a automatically generated integer. The B-Tree key for a row can always be accessed using one of the special names "ROWID", "OID", or "_ROWID_". This is true regardless of whether or not there is an INTEGER PRIMARY KEY. An INTEGER PRIMARY KEY column man also include the keyword AUTOINCREMENT. The AUTOINCREMENT keyword modified the way that B-Tree keys are automatically generated. Additional detail on automatic B-Tree key generation is available separately.

Da sich meine PPC-Anwendung auf die ROWID stützt, stehe ich dem Primarykey eher skeptisch gegenüber weil der B_Tree Key als ROWID hervorragend zur Anzeige der aktuellen Position z.B.: 1/51000 geeignet ist.


Schönen Abend noch

Grüße
berndgoedecke

 

[Fontanus]

Hallo berndgoedecke

Meine Frage zum Thema Normalisierung hat zwar auch mit Indizierung zu tun, es sind aber grundsätzliche Regeln zum Aufbau von Datenbanken. Deshalb, und im Besonderen wegen der 27 Tabellenfelder, die Frage danach.

Es gibt mehrere Stufen der Normalisierung, die man sinnvollerweise beim Planen und Erstellen einer Datenbank berücksichtigen sollte. Die Tiefe der Normalisierung ist umstritten, denn man kann dabei auch verschlimmbessern.

Ich habe in meiner Datenbank 9 Tabellen, die miteinander über Relationen verknüpft sind. Bei vielen Datensätzen läßt sich darüber die Datenmenge und auch die Geschwindigkeit der DB stark reduzieren. In manchen Eingabe- oder Suchmasken greife ich per SQL-Abfrage auf mehrere Tabellen gleichzeitig zu um das gewünschte Ergebnis zu erhalten.

Im Netz gibt es diverse Seiten zum Aufbau relationaler Datenbanken mit den Normalisierungsregeln.

Nachdem meine Anwendung mittlerweile praxistauglich ist, kann ich nur sagen, daß sich der Aufwand bei der Planung gelohnt hat. Minimaler Aufwand bei der Datenpflege ist der Lohn der früheren Arbeit.

Wenn Du dies aber schon berücksichtigt hast, dann laß uns zu den aktuellen Problemen kommen.

Gruß

Fontanus

 

[berndgoedecke]

Hallo Fontanus,
offengestanden habe ich mir über Normalisierung, bei meiner Anwendung noch nicht viele Gedanken gemacht, weil ich einen vorgegebenen Datenbestand habe, und ich denke, dass SAP bei der Erstellung seiner Standard-Tabellen diesen Umstand berücksichtigt hat.

Mir geht es darum SQLite auf dem PDA, auch für nicht oder zumindest wenig Datenbankinterssierte anwendbar zu machen, sprich: Filtern mit Hilfe graphischer oder tabeblarer Elemente, die ähnlich wie in Access im Programm angewählt werden können und vom Programm entsprechende SQL-Abfragen generiert werden.
In meinem Fall ist es wenig hilfreich, wenn nur Leute mit dem Programm umgehen können, die des SQL's mächtig sind. Es geht darum die Daten, trotz des begrenzten Platzes übersichtlich darzustellen, auf einfache Weise suchen und Filtern zu können.
Die Verknüpfung von Tabellen mit inner-, outer- cross Join, ist für mich erst interessant, wenn ich den Stand erreicht habe den ich mit NSBasic bereits erreicht hatte.
Da ich das aber als Hobby betreibe, steht leider nur wenig Zeit zur Verfügung, so das es noch eine Weile dauern wird.

Viele Grüße

berndgoedecke

 

[Rallig]

Moin,

generell denke ich auch eher, dass gerade für sein Hobby -einwenigProgrammieren- jeder nach gut dünken arbeiten sollte.

Hier sehe ich aber auch wie Fontanus ein riesengroßes Warnschild.

Also wenn Du noch am Anfang stehst, wäre das doch jetzt die beste Möglichkeit, den Datenbestand so umzugestalten, dass Du auch die Macht von relationalen Datenbanken ausnutzen kannst.

Du erwähntest zum Beispiel Partnersätze. Für mich klang das jetzt wie "Redundanz". Wäre das nicht schon ein guter Ansatz ? Um die Programmierung von SQL-Statements brauchst Du Dir zum Erstellungszeitpunkts eines ERM's wohl die wenigsten Gedanken machen. Auch "Joins" kannst Du generieren, so dass der Benutzer von SQL keine Ahnung haben braucht.

Gerade wenn das eigentliche Ziel dann erreicht ist, und man selber noch viel langeweile hat und sein Programm erweitern möchte, ist es viel einfacher auf ein gutes Grundgerüst aufzusetzen. Gerade wenn der Datenbestand etwas modularer gehalten wurde.

Aber selbstverständlich weiss ich auch :"Manchmal geht es einfach nicht einfach !"

Ich kann aber auch mal eine Frage SQLite <-> B4P reinstreuen.
Wie handelt ihr Fließkommazahlen ab ? Wenn ich Daten aus der DB ziehe, die noch ein paar Nachkommastellen haben, wird das Komma direkt mal ignoriert.
Es sei denn ich ersetze das Komma als "," durch "." (Funktion StrReplace(...))
Ich finde das so dermassen unschön. Habt ihr da irgendwelche Erfahrung mit machen können ?

 

[berndgoedecke]

Hallo Rallig,
in welchem Steuerelement stellst du denn deine Fließkomma-Zahlen dar?
Ohne irgendwelche StrReplace-Klimmzüge geht das in Filippos ListView.
Das Formatierungsproblem, das ich habe, ist: Was machen wir mit einem Datum, oder einer Zeit? DateFormat("dd.mm.yyyy") wirkt sich offensichtlich nicht auf den Zellen-Inhalt des LitViews aus.

 

[Fontanus]

Hallo berndgoedecke und Ralling

Wie Ralling schon sagte, sollte die Anwendung, die auf den Datenbestand zugreift, alle SQL-Abfragen schon weitestgehend abdecken. Ich habe mir für das Erstellen komplexer Abfragen das Tool SQLiteExpert zugelegt. Damit lassen sich alle Abfragen durch grafische Verknüpfungen relativ einfach erstellen, inkl. aller Joins etc.

Ein wenig Vorarbeit ist natürlich erforderlich bei der Definition der einzelnen Tabellen und der Felder, die für die Verknüpfung der Tabellen erforderlich sind.

Aber, um es noch einmal zu verdeutlichen: Der Anwender sieht und spürt davon nichts. Bis auf die einfache Möglichkeit zur Datenpflege. Und daß das so ist, liegt an der Arbeit des Entwicklers/Programmieres.

Ich stimme Ralling natürlich in dem Punkt zu, daß jeder nach seinem Gutdünken vorgehen kann und auch sollte.

Fließkommazahlen habe ich nicht abzuhandeln und demnach auch keine Erfahrung. Das Thema interessiert mich aber auch, wegen künftiger, neuer Aufgabenstellungen.

Schönen Tag noch

Fontanus

 

[berndgoedecke]

Lösung in Sicht

Hallo Fontanus,
zu diesem Problem und anderen Formatierungen, gibt es aktuelle Entwicklungen von Filippo. Ich konnte zwar noch nicht alles im einzelnen testen, aber die neue ListView.dll macht einen sehr guten Eindruck.
Schau doch mal hier:

http://www.b4x.com/forum/german-forum/352-listview-dll-5.html#post13259

Viele Grüße

berndgoedecke

 

[Rallig]

Die Listview wird ja heiss diskutiert. Da schau ich mir mal das Meisterwerk von Filippo doch gerne mal an.

Ich befürchte aber, dass das mein Fließkommaproblem nicht lösen wird. Ich hole meine Daten aus der GetValue-Methode. Und die liefert dann halt nur einen String. Ich befürchte das wird dann nicht richtig gecastet.

 

[berndgoedecke]

Real Problem

Hallo Rallig,
ich habe jetzt auch ein Problem mit Real und dessen Darstelllung, wie du bereits in Post #13 angemerkt hast. Ich glaube, dass das in der Version 3.3.1.2 von SQLite auch noch nicht so richtig rund läuft. (Siehe auch die Anfrage im englischsprachigem Forum.)

Hast du da inzwischen mehr herausgefunden?

Ach übrigens: Die Produktion des Converters, wie in Post#3 angekündigt läuft ganz gut, dabei bin ich dann auch auf das Real-Problem gestoßen.
Es geht dabei aber nicht um die Darstellung als Real sondern das Ablegen eines Real-Wertes in eine Tabelle, nach Konvertierung eines Strings.

Viele Grüße

Bernd Gödecke

 

[Rallig]

Hallo Bernd,

ich habe jetzt ehrlich gesagt mich nicht mehr weiter drum gekümmert, da ich ja grundlegend mein Ziel, also mein Programm fertigstellen, verfolge.
Da wäre es schön gewesen nicht irgendwelche anderen Wege gehen zu müssen, aber da es diesen Weg halt gibt, dann gehe ich ihn ... hmmmm

Ich vermeide also Fließkomma wo es geht. Beispiel bei meinem Programm : Gewichtsangabe im PPC = 87.56 kg ... das Multipliziere ich mit 10 und nehme den Ganzwert. Trage also 875 in die DB ein. Ist vielleicht unschön, da man jetzt wissen sollte, dass dieser noch mit 10 beim Selektieren dividiert werden muss.
Aber ich habe mich damit abgefunden

Gruß Rallig

 

[JOTHA]

Ja, mich interessiert das auch ...

Ich bin zwar kein Profi, aber mich interessiert ebenfalls SQLite.

Ich arbeite zur Zeit an einer Preisliste mit ca. 8.000 Datensätzen in 24 Spalten.

Um das Ganze zu beschleunigen, lade ich nicht die ganze Datenbank in den Speicher, sondern suche mir nur die passenden Begriffe raus und lasse sie dann in einer Tabelle anzeigen.

Jetzt habe ich nur ein Problem.

Wie kann ich Datensätze neu hinzufügen, editieren oder löschen, wenn ich nicht die ganze Datenbank geladen habe?

Das müsste doch auch gehen über ...

'     Connection.New1
'   DataReader.New1
'   Command.New1("",Connection.Value)
'   'Öffnet eine "Connection" mit der angegebenen Datenbank:
'   Connection.Open("Data Source = " & Database) 'Database ist bei "Globals" eingetragen

... oder?

Weiß da jemand Bescheid?