PROJEKT: SQLite - C++ WRAPPER KLASSE [MFC]
-
@ renel:
frohes neues!
gut ins neue jahr gekommen? weisst du jetzt bescheid, ob du zeit für sqlite hättest?
kennst du noch leute die an dieser arbeit interessiert wären?
-
Frohes neues auch von mir! Nein weiß noch nicht, ob ich Zeit dafür hätte. Bekomme die Nachricht, die alles entscheidet frühestens morgen.
Hab SQLite mal unter härteren Bedingungen getestet. Hab eine Tabelle mal mit Börsendaten vollgefüllt. Das sind ca. 1,2 Millionen Reihen á 10 Spalten. Ein "Select * From Quotes" dauert dabei ca. 13 Sekunden über meine Wrapper-Klasse. Die Daten sind dann voll abfragebereit! Dank Pointerarithmetik und MemoryStorage der Daten ist alles sofort verfügbar.
Datenbank ist mit allen Daten ungefähr 87MB groß. Werde demnächst auch noch Gelegenheit haben mySQL embedded und BerkeleyDB zu testen. Mal sehen, ob die schneller sind!
Leute kenne ich keine!
-
2 fragen:
welche version nutzt du?
binaries 4 windows? oder compilierst du selbst? das letzte versuche ich selber gerade irgendwie hinzubekommen. klappt aber leider nicht so wie ich es will. ehr gar nicht.arbeitest du mit threads? ich überlege gerade wie ich das problem mit grossen datenmengen löse.
die wartezeit lässt sich nicht vermeiden. bloss, entweder läuft die anwendung und da ist irgendwo ein statusbalken, der anzeigt wie weit die queries voranschreiten, oder die anwendung reagiert sekundenlang gar nicht.definiere MemoryStorage
-
Mal ne andere Frage .... wenn ihr euch schon die muehe so macht, und vielen codern SQLLite naeher bringen wollt, und euch an M$ binden muesst, warum schreibts ned nen ADODB-Provider. Die Schnittstelle ist spezifiziert, und ned nur auf C++ beschraenkt ... (macht das schreiben und testen von prototypen in VB moeglich, ausserdem wirds mittels VB Script oder jeder anderen sprache, die ActiveX kann, Scriptfaehig ... )
Und keiner muss sich an die 10000ste neudefinition von RecordSets gewoehnen ...Ciao ...
-
RHBaum schrieb:
Mal ne andere Frage .... wenn ihr euch schon die muehe so macht, und vielen codern SQLLite naeher bringen wollt, und euch an M$ binden muesst, warum schreibts ned nen ADODB-Provider. Die Schnittstelle ist spezifiziert, und ned nur auf C++ beschraenkt ... (macht das schreiben und testen von prototypen in VB moeglich, ausserdem wirds mittels VB Script oder jeder anderen sprache, die ActiveX kann, Scriptfaehig ... )
Und keiner muss sich an die 10000ste neudefinition von RecordSets gewoehnen ...Ciao ...
hier kann ich auch nur für mich persönlich sprechen: es ist ganz und gar nicht so, dass ich mich an microsoft produkte binden 'muss'. ich möchte damit bloss erfahrungen sammeln, da ich in der industrie später sicher auf dieser platform arbeiten muss.
leider ist es so, dass es nicht immer sinnvoll ist bestehende strukturen auf linux umzustellen, da die umschulung des personals einfach zu teuer wäre. deshalb lerne ich alles doppelt, damit ich villeicht zu der generation gehöre, die irgendwann einfacher einen umstieg durchführen kann, weil sie mit beiden systemen vertraut ist. persönlich fühle ich mich ehr zu linux hingezogen, weil mir die einstellung der leute einfach besser gefällt.
im letzten satz sprichst du davon, dass wir hier das rad neu erfinden. ich denke, du hast vollkommen unrecht. denn, wenn man sich etwas mit sqlite beschäfftigt hat, merkt man, dass es teilweise deutlich anders ist als andere dbms. zum einen der aufbau, es ist eine einzige bibliothek, die sehr mächtig ist. zum anderen ist es der einsatzbereich. zwar gibt es schon mehrere projekte, die auf verschiedene weise die netzwerkfähigkeit hinzufügen, allerdings ist in meinen augen auch so eine vollständiges projekt. denn es erfüllt den zweck einer lokalen datenbank.
ausserdem, wäre es nicht eine neudefinition, wenn man einen adodb treiber schreiben würde. ehrlich ich habe keine ahnung wie ich das machen könnte. aber ich weiss in etwa was du meinst. und jetzt überleg doch mal selbst, wieso sollte ich dann sqlite nehmen? wieso die mühe? ich kann dann doch schon auf bestehende produkte zurückgreiffen.
so viel zeit steht mir leider auch nicht zur verfügung. deshalb versuche ich einfach etwas zu schaffen, dass vielleicht auch nur ein paar leute irgendwo einsetzen können, und zwar aus dem grund, weil sie eine mücke nicht mit einer a-bombe bekämpfen wollen.der sinn dessen, was ich mache liegt darin, dass mir viele andere dbms einfach zu viel bieten, und leider deshalb auch zu viel last tragen.
die performance, die ich mit sqlite in meinen programmen erziele, übertrifft selbst die grossen dbms. deshalb sehe ich keinen grund, für dieses projekt eine krücke zu schreiben, die alle vorteile vernichtet.
und irgendwo hast du ja auch recht, dass man sich wieder an etwas neues gewöhnen müsste. aber müssen wir das nicht alle tun, früher oder später? das system mit dem du, oder irgendjemand anders momentan arbeitest, wird später durch ein anderes ersetzt. dann musst du dich wieder umgewöhnung. also ich denke, es ist gut so, wie es ist. aber es ist nicht perfekt.
-
Aehhh ok, ich verstehe .... naja, teileweise :p
im letzten satz sprichst du davon, dass wir hier das rad neu erfinden.
nein, so meint ich das nicht, sicher wird es bei jeder implementation immer irgend eine besonderheit geben, also waere es sowas wie nen speichenrad erfinden, wenn es schon nen Holzrad aus nem zersaegten Baumstamm gibt :p
Was ich meine ist eher ... In der Praxis gibt es Tonnen von DBMS systemen, einer schoener und langsammer als das andere (Oracle, MSSqlServer ...)einige schneller (msql) manche als Simple Filesysteme ohne schnickschnack, dafuer noch schneller (BerkleyDB, SQLLite gehoert auch hierein, glaub ich).
Das Problem ist, das jedes DBMS ne eigene API auf C-Ebene mitbringt (OCI, libmysql ...) in die man sich einlernen muss. OK, sollte ned so das problem sein, aber wenn ploetzlich der kunde von einem DBMS aufs andere migriert, gehen die probleme los ...
Unter windows nimmt man dann vorrausschauender weise solche schnittstellen wie odbc, oder ADODB wenn es sie gibt ...Soviel ich ueber SQLLite gelesen hab, erhebt es halt den anspruch ein schnelles rudimentaeres SQLSystem zu sein, ohne viel schnickschnack, was eigentlich nur Dateizugriff auf SQL Ebene realisiert. Alle anderen "Datenbankfunktionen" bleiben aussen vor.
Damit steht es fuer mich in der Mitte zwischen ner richtigen Datenbank ... (klar, nimmt man wenn es sich lohnt) oder eigene Datenklassen, die sich selber serialisieren koennen ... Ob ich dann nun mir die muehe mache, nen eigenes Fileformat zu definieren (nehmen wir mal an, XML ist zu viel overhaed) oder eine Loesung ala sqllite ... haengt sicher auch von den vorhandenen schnittstellen ab. Wenn ich ne spezielle SQLLite API hab, bin ich eh schon wieder gebunden. Und da der Kopf meist schon voll mit OCI mysql etc ist, tut man sich da here schwer, geht mir zumindest so ...
Ich will euch hier ned den Mut nehmen, und ich bin sicher auch kein riesen fan von MS Datenbankschnittstellen ... Ich denk nur an meinen Kopf, und wie man halt so nen Project mehreren Leuten zugaenglich machen koennte ...
Wenn man sich anschaut was MS gemacht hat, sieht man sogar nen sinn dahinter ...
Alle datenbanken haben folgende "Objecte" gemeinsamm ... eine Connection, eine Abfrage, eine tabelle ,ein recordset, ein feld.
Nur warum muss unter C++ das Oracle DB Object anders aussehen, als das mysql object ... Ab ner bestimmten ebene sowieso, klar, aber wieso auf anwenderebene ? Kommt es bei DB so auf die geschwindigkeit an ? Glaub eher ned.
Warum gibt keine generischen DB objecte unter C++, wo man, von mir aus beim linken, damit mans ned zu dynamisch machen muesst, festlegt, was fuer ne DB dahinter steht ?
Grad fuer Linux waer das revolutioniear. Naja, vielleicht schreibt auch wer mal nen KPart fuer Datenbanken, wo man genau das mit macht ... wuerde zumindest KDE sicher nach vorn bringen ...
Aber das isst eher nen generisches softwaretechnisches Problem.Nur wie gesagt, ihr wollt euch an Windows binden (was durchaus berechtigte Gruende haben kann), dann liegt das halt nahe.
Und zum Thema Geschwindigkeit ...
Ich denk mal, wenn ich statt nem binaeren filezugriff SQL-Strings parsen muss, um dateien zu befuellen, spielt dann nen ActiveX zugriff auch keine rolle mehr, besonders wenn er eh inprocess ist ... Bei FIleIO zugriffen macht es allgemein nimmer soviel aus, wenn es einigermassen gut gecodet ist.
Will ich dagegen richtig Geschwindigkeit, nehme ich halt ned SQL ...Wenn ihr ne Version fertigt habt, checkt mal eure Laufzeit gegen die, wenn man mittels ADODB in ne .mdb datei schreibt. Um euer System durchzusetzen, muesstet ihr schon significant schneller sein.
Und heee, das sind nur meine gedanken zu, besonders zu diesen Saetzen:
kurz: für alle! als ich dieses projekt entdeckt habe, konnte ich nach der einarbeitungsphase nicht glauben, dass ich nicht schon früher davon gehört habe. allerdings ist es nicht so benutzerfreundlich wie manch (halb-)kommerzielle lösungen. es gibt auch schon einige projekte, auf denen dieses projekt aufbauen soll, die es auch für einsteiger attraktiver machen sollen. diesen weg möchte ich mit diesem projekt ausbauen.
Ich sehe die binaere Welt sicher aus nem anderen Blickwinkel. Wenn es euch spass macht, ihr dabei lernt, und zum schluss sogar was bei rauskommt, warum nicht ?
Ciao ...
-
RHBaum schrieb:
Aehhh ok, ich verstehe .... naja, teileweise :p
im letzten satz sprichst du davon, dass wir hier das rad neu erfinden.
nein, so meint ich das nicht, sicher wird es bei jeder implementation immer irgend eine besonderheit geben, also waere es sowas wie nen speichenrad erfinden, wenn es schon nen Holzrad aus nem zersaegten Baumstamm gibt :p
weiss nicht ob das jetzt so äquivalent ist, aber gut. für mich hat sqlite einen sinn, und da ich auch die mailinglist verfolge, merke ich, dass es auf für viele andere leute einen sinn ergibt. neben dem 1st man hinter sqlite D. Richard Hipp, gibt es einige weitere personen, die schon etwas länger an diesem oder an anderen anspruchsvollen projekten gearbeitet haben. im grunde kümmern sich diese leute darum, dass auch die 'letzten fehler' /*jede kompliziertere software hat einfach ihre fehler. fehlerfreie programme gibt es nie.*/ aus dem code geräumt werden.
alleine in der mailing list haben sich einige firmen zu wort gemeldet, die kommerzielle produkte auf basis von sqlite vermarkten. ich denke da finden die leute mit einem etwas dickeren portemoney auch etwas womit sie glücklich werden.
ich für meinen teil bin bescheidener, und bin schon damit zufrieden, dass das ganze wunderbar funktioniert.Was ich meine ist eher ... In der Praxis gibt es Tonnen von DBMS systemen, einer schoener und langsammer als das andere (Oracle, MSSqlServer ...)einige schneller (msql) manche als Simple Filesysteme ohne schnickschnack, dafuer noch schneller (BerkleyDB, SQLLite gehoert auch hierein, glaub ich).
Das Problem ist, das jedes DBMS ne eigene API auf C-Ebene mitbringt (OCI, libmysql ...) in die man sich einlernen muss. OK, sollte ned so das problem sein, aber wenn ploetzlich der kunde von einem DBMS aufs andere migriert, gehen die probleme los ...
Unter windows nimmt man dann vorrausschauender weise solche schnittstellen wie odbc, oder ADODB wenn es sie gibt ...dazu möchte ich natürlich auch etwas sagen.
dass so viele datenbank system samt api in der sprach c geschrieben sind, hat seine trifftige gründe, die eigentlich jedem bekannt sein sollten. ich meine ja nur. wer würde auf die idee kommen, eine db-engine in basic, oder in delphi zu schreiben? ich schätze das wäre eine kleine untermenge.
c ist sehr nah an der maschinensprache, bietet einem guten c programmierer sehr viele möglichkeiten, gutes und ungutes zu tun. als motor einer datenbank ist es sehr gut.
natürlich ist es etwas anderes, wenn es um das cocpit geht. dieses sollte schon bedienungsfreundlicher sein und den fahrer nicht mit hunderten schaltern und dutzenden pedalen überfordern.
deshalb bemühen sich leute wie ich um eine eigene api schicht, die an die eigenen bedürfnisse angepasst ist. umständlich? sicherlich nicht. denn erst jetzt habe ich überhaupt die leiseste ahnung davon, was bei mir unter der haube los ist. ich kann fehler schneller entdecken und korrigieren, ich weiss welcher code schneller ist, welcher bequemer.
dieses bietet dir kein odbc.
denn, gerade bei odbc geht die gesamte entwicklung in richtung kompromisse. wenn man schon die odbc schnittstelle benutzt, dann erübrigt sich schon die suche nach einem dbms, denn dann kann man praktisch alles benutzen. dieser vorteil bringt natürlich auch nachteile mit sich!
mit odbc kann man eine db-engine niemals richtig ausreizen. die kompromisse, die durch die kompatibilitätsfragen, verhindern die optimierung der schnittstelle an eine besondere datenbank-engine. dies trifft natürlich nicht 100% zu und unterscheidet sich von dbms zu dbms, aber ich schätze, dass es oft passiert, das softwareentwickler bei der arbeit an einem odbc treiber sich über die vorgaben ärgern, weil es dann nicht möglich ist, die vorteile der eigenen db zu zeigen.migrationsprobleme?
nun, vielleicht habe ich es nicht deutlich genug getextet. mein projekt ist modular aufgebaut und auch schon etwas vorausgeplant. ich selbst werde meine wrapper class nicht nur mit mfc unterstützung anbieten, sondern portiere diese auch nach qt und gtk.
andere module die ich auch in meine klasse miteinbeziehe, wie das log system und den internet updater, werde ich ebenfalls mit einer identischen schnittstelle anbieten, damit die klassen für verschiedene systeme portabel bleiben.Soviel ich ueber SQLLite gelesen hab, erhebt es halt den anspruch ein schnelles rudimentaeres SQLSystem zu sein, ohne viel schnickschnack, was eigentlich nur Dateizugriff auf SQL Ebene realisiert. Alle anderen "Datenbankfunktionen" bleiben aussen vor.
das stimmt nicht! da hättest du dich vielleicht etwas besser informieren sollen. sqlite bietet auf der api ebene den sql92 std.. wobei dort 2 oder 3 sachen fehlen. die meiner meinung nach nicht wesentlich sind. vermissen tut man sie auch nicht.
und datenbankfunktionen sind bei sqlite gerade schwer im kommen. es gibt sie also, und einige leute arbeiten daran, dass mehr solcher funktionen in zukünftigen releases ans tageslicht kommen.
ausserdem bietet sqlite einige funktionalitäten, die ich bei keinem anderen dbms gesehen habe und die sehr attraktiv sind.
z.b. transactions, precompiled queries
alleine mit hilfe dieser beiden techniken, lassen sich sqlite anwendungen so optimieren, dass die performance um den faktor 2 oder 3 besser ist als bei dbms wie mysql oder postgresql.ohne viel schnickschnack - da hast du vollkommen recht. und ich denke, gerade, wenn man anwendungen programmiert, baut man sich schon zu viel schnickschnack ein. da wäre es doch schade, wenn man die performance wegen schnickschnack, den man gar nicht benötigt, geschweige denn benutzt, verliert.
Damit steht es fuer mich in der Mitte zwischen ner richtigen Datenbank ... (klar, nimmt man wenn es sich lohnt) oder eigene Datenklassen, die sich selber serialisieren koennen ... Ob ich dann nun mir die muehe mache, nen eigenes Fileformat zu definieren (nehmen wir mal an, XML ist zu viel overhaed) oder eine Loesung ala sqllite ... haengt sicher auch von den vorhandenen schnittstellen ab. Wenn ich ne spezielle SQLLite API hab, bin ich eh schon wieder gebunden. Und da der Kopf meist schon voll mit OCI mysql etc ist, tut man sich da here schwer, geht mir zumindest so ...
db? meinst, dbms.
sqlite ist ein richtiges dbms!
man sollte sich über dieses projekt lieber vorher genauer informieren, anstatt es als bessere datenbank klasse abzustempeln. denn wenn man das tut müsste man gleiches bei allen 'richtigen' datenbanken ebenfalls tun.
wenn ich sqlite benutzte, dann weil ich eine datenbank benötige, nicht weil ich einfaches daten storage betreiben muss. du irrst, wenn du das behauptest. natürlich kann man es auch so gebrauchen, aber das kann man mir jedem dbms tun.und, wie schon erwähnt es soll meine wrapper class werden, die eine api nach meinen vorstellungen bietet. ich habe mir viele api's und einige wrapper klassen angeschaut, und bin zu dem subjektiven schluss gekommen, dass das ganz gut ist.
nur, es ist eine wrapper klasse! d.h. ich könnte meine schnittstelle genauso gut auf mysql++ übertragen. und auf einige andere dbms-api's ebenfalls. somit hätte ich eine weitere schicht, die transparent genug ist, um sie an andere dbms anzupassen.
ich weiss nicht, vielleicht habe ich einfach eine andere definition von wrapper klassen, aber ich habe diese idee gehabt, damit ich später, bei einem möglichem umzug auf ein andere dbms einfach meine classe ändere, meine anwendungen aber nicht! das ist der sinn des objekt orientieren, so meine wenigkeit. und ich denke, da werden mir noch einige leute zustimmen, dass es was brauchbares ist und keine zeitverschwendung.Ich will euch hier ned den Mut nehmen, und ich bin sicher auch kein riesen fan von MS Datenbankschnittstellen ... Ich denk nur an meinen Kopf, und wie man halt so nen Project mehreren Leuten zugaenglich machen koennte ...
wieso mut nehmen? meinungen austauschen bring die obermenge weiter.
anders, es ist deine meinung. ich habe auch eine eigene. das ist auch gut so!ehrlich gesagt, bin ich es auch nicht. und noch ehrlicher, microsoft hat selber keine dbms produziert, zumindest nicht in den ersten 20 jahren nach der firmengründung. viele produktfamilien, die microsoft vertreibt, sind aufgekauft.
die ersten versionen von visual c++ konnten mit datenbanken nicht viel anfangen. und auch microsoft glaubte nicht an den trend, dass datenbanken einfach nötig sind, um daten von anwendungen zu trennen. und vor allem anwendungen von daten zu trennen, damit auch andere anwendungen zugriff haben.
ich weiss noch, dass delphi - liegt ja eigentlich schon im namen - eine sprache war die seit der geburt darauf getrimmt war mit datenbanken zu arbeiten. so weit ich weiss tut es dies auch sehr gut.microsoft ist zwar ein grosses software und system haus, aber das meiste geld verdienen die redmonter mit der vermarktung von programmen, die ursprünglich nicht im eigenen hause entwickelt wurden. es ist aber lange nicht so, dass sie nur software kaufen und dann weiterentwickeln um sie zu vermarkten, nein, etwas schlauer sind schon. man kauft die leute, die die software für sie entwerfen.
es gibt so viele programme, die andere firmen entwickelt haben und als microsoft dann merkte, dass sich diese gut entwickeln, engagieren sie einfach ein paar hundert programmierer, stellen ein paar teams zusammen, clonen nach möglichkeiten die software und 'verbessern' sie nebenbei, bevor es unter dem titel 'nt' auf den markt kommt. genau das gleiche passiert auch mit der kompletten datenbank sparte.und wenn du schon meinst, dass man auf etwas setzen sollte das zukunft hat, damit man sich nicht umgewöhnen müsste, damit man auch nicht alles ändern müsste, dann wiedersprichst du dich hiermit.
so weit ich das mitbekommen habe spielt microsoft pocker mit den ganzen db standards. mal ist das die zukunft, und ein jahr später (nach dem es von denprogrammierern nicht angenommen wird) ist gleich mal etwas anderes die zukunft.
nun wie soll ich es am besten formulieren. microsoft, war nie und wird nie ein trendsetter sein. andere firmen wie apple schon eher. auch wenn sich apple vielleicht nicht ganz durchsetzen wird. dafür kann man jetzt in osdl die hoffnung stecken.
es ist ein sehr kompliziertes thema, und ich finde man sollte das nicht in ein paar sätzen einfach so manifistieren. die strategien bestimmter firmen, können sich immer ändern. zukunftssicherheit ist dabei einfach nicht definiert!aus diesem grund habe ich mich vielleicht auch für sqlite entschieden. wenn dort irgendwelche neuen entwicklungen in den cvs tree gelangen, dann nur weil es langsam zeit dafür wird, und nicht, weil man die leute mit irgendwelchen neuen funktionen locken will, die einem das leben so viel leichter machen sollen. es wird durch diese ganzen schnickschnack funktionen meistens nicht leichter, zumindest ist das nur so der schein.
Wenn man sich anschaut was MS gemacht hat, sieht man sogar nen sinn dahinter ...
tut mir leid, auch wenn ich mich bemühe, hinter dem was microsoft meistens macht, sehe ich absolut keinen legitimen sinn! der einzige sinn den ich in den strategien von microsoft sehe wird manchmal scherzhaft mit der umschreibung des firmennamens in micro$oft deutlich. möglichst oft releasen. und wenn das jahr nur 6 monate hätte, würden neue versionen auch alle 6 monate rauskommen.
Alle datenbanken haben folgende "Objecte" gemeinsamm ... eine Connection, eine Abfrage, eine tabelle ,ein recordset, ein feld.
Nur warum muss unter C++ das Oracle DB Object anders aussehen, als das mysql object ... Ab ner bestimmten ebene sowieso, klar, aber wieso auf anwenderebene ? Kommt es bei DB so auf die geschwindigkeit an ? Glaub eher ned.
Warum gibt keine generischen DB objecte unter C++, wo man, von mir aus beim linken, damit mans ned zu dynamisch machen muesst, festlegt, was fuer ne DB dahinter steht ?ja, man könnte sich auf einen standard einigen. diesen kann man dann bei neuen programmiersprachen wieder neu definieren usw. gerade wenn du mit microsoft als retter der lage ansprichst. was meinst du wie lange sich c# halten wird? was meinst du wie schnell microsoft reagieren wird und ein c#+-xy rausbringt? und dann von einem standard reden? bis sich in der heutigen zeit ein standard richtig durchgesetzt hat, wird es schon zeit für den nächsten.
alleine deshalb finde ich, dass die strategie - core in c, api in c und ein eigener wrapper in c++/mfc/qt/gt/... - eigentlich noch sinn hat, denn ich brauche 2 tage maximal, um meine wrapperklasse in einer anderen sprache zu clonen. muss ich etwas an der anwendung ändern? nein.
Grad fuer Linux waer das revolutioniear. Naja, vielleicht schreibt auch wer mal nen KPart fuer Datenbanken, wo man genau das mit macht ... wuerde zumindest KDE sicher nach vorn bringen ...
Aber das isst eher nen generisches softwaretechnisches Problem.du vergisst etwas. viele vergessen etwas. hinter linux verbirgt sich nicht so viel geld und habgier, dafür um so mehr potenzial.
allerdings ist linux auch nicht perfekt. aber es wird ständig weiterentwickelt. vor ein paar tagen war in der mailiglist eine nachricht von D. Richard Hipp, in der er einen fehler in der lock funktion der core beschreibt. diesen hatte er schon analysiert und am nächsten tag behoben und die neue version getestet. der fehler war auf einen design fehler in der posix umsetzung oder im posix selbst zu finden.
also, das war recht beeindruckend. es ging recht schnell. innerhalb von ein paar stunden, war der fehler gefunden, beseitigt und getestet worden.
ehrlich gesagt, bin ich gespannt, wie sich das ganze entwickeln wird, linux und co.
aber man sollte den tag nicht vor dem abend loben.Nur wie gesagt, ihr wollt euch an Windows binden (was durchaus berechtigte Gruende haben kann), dann liegt das halt nahe.
hat jemand was von binden gasagt? hab ja schon etwas dazu geschrieben, also s.o.
Und zum Thema Geschwindigkeit ...
Ich denk mal, wenn ich statt nem binaeren filezugriff SQL-Strings parsen muss, um dateien zu befuellen, spielt dann nen ActiveX zugriff auch keine rolle mehr, besonders wenn er eh inprocess ist ... Bei FIleIO zugriffen macht es allgemein nimmer soviel aus, wenn es einigermassen gut gecodet ist.
Will ich dagegen richtig Geschwindigkeit, nehme ich halt ned SQL ...wie gesagt, sqlite ist keine dateiklasse oä!
es ist ein vollständiges rdbms!Implements most of SQL92. (Features not supported)
A complete database (with multiple tables and indices) is stored in a single disk file.
ACID (Atomic, Consistent, Isolated, Durable) transactions.
Database files can be freely shared between machines with different byte orders.
Supports databases up to 2 terabytes (2^41 bytes) in size.
Small memory footprint: less than 25K lines of C code.
Two times faster than PostgreSQL and MySQL for many common operations.
Very simple C/C++ interface requires the use of only three functions and one opaque structure.
TCL bindings included. Bindings for many other languages available separately.
Simple, well-commented source code.
Automated test suite provides over 90% code coverage.
Self-contained: no external dependencies.
Built and tested under Linux and Windows.
Sources are in the public domain. Use for any purpose.und ja, sqlite hat, wenn man programme optimiert, sehr grosse performance vorteile!
ausserdem, wenn ich deinen post so lese, dann habe ich die leise ahnung, dass es für dich keinen unterschied gibt, zwischen einer sql db und einer datei mit content.
den gibt es!Wenn ihr ne Version fertigt habt, checkt mal eure Laufzeit gegen die, wenn man mittels ADODB in ne .mdb datei schreibt. Um euer System durchzusetzen, muesstet ihr schon significant schneller sein.
ich glaube ich brauche das nicht einmal mit zahlen zu belegen. jeder der sqlite und access über odbc (z.b. meine wenigkeit) in seinem programm hat einmal laufen lassen, wird bestätigen, dass es einen grossen unterschied gibt. also, selbst bei kleinigkeiten. extremfall: eine kleine db, ein eintrag, username, passwort.
für sqlite ein nichts. es läuft alles sauber und keinerlei verzögerungen.
bei der access lösung dagegen rattert kurz die festplatte und eine halbe sekunde verzögerung. ist zwar nicht viel, aber es ist ein deutlicher unterschied.
genau so bei grossen mengen an daten. in einer schleife 20000 einträge speichern lassen. access lösung nach ein paar minuten 'reagiert nicht mehr' gekillt. und sqlite war in einer guten minute fertig.
das besondere: die prozessorauslastung war bei sqlite so, dass man noch nebenbei etwas anderes machen konnte.Und heee, das sind nur meine gedanken zu, besonders zu diesen Saetzen:
kurz: für alle! als ich dieses projekt entdeckt habe, konnte ich nach der einarbeitungsphase nicht glauben, dass ich nicht schon früher davon gehört habe. allerdings ist es nicht so benutzerfreundlich wie manch (halb-)kommerzielle lösungen. es gibt auch schon einige projekte, auf denen dieses projekt aufbauen soll, die es auch für einsteiger attraktiver machen sollen. diesen weg möchte ich mit diesem projekt ausbauen.
Ich sehe die binaere Welt sicher aus nem anderen Blickwinkel. Wenn es euch spass macht, ihr dabei lernt, und zum schluss sogar was bei rauskommt, warum nicht ?
du siehst eine binäre welt? hm. ich nicht.
aber RHBaum, persönliches wort: du hast deine meinung, ich habe meine meinung zu diesem thema, finde, man kann verschiedene meinungen haben. sollte besser von anderen meinungen wissen. das ist was gutes. aber jemanden von der eigenen meinung überzeugen ist nicht gerade fair.
danke dir für deine meinung. ich diskutiere gerne. aber schön auf der sachebene. dem einen machts spass. der andere will vielleicht auch etwas für die zukunft lernen. ein dritter könnte irgendwann geld damit verdienen.
gruss
alex-t
-
ok, nur noch "kurz" dazu ...
1. klar darfst deine eigene Meinung haben, ist auch gut so ... !
2. Ok, mein Fehler, ich hab mir die Site von Sqllite angeschaut, und die einleitung gelesen. Und auch auf paar anderen Seiten die Kommentare zu. Klang fuer mich eher wie ne "einfache" datenbank engine. Wenn man weiter liesst (Asche auf mein Haupt), ok es ist doch eher nen dbms .
3. Ich seh die Welt ned nur von seite der Entwickler, sondern auch von der Betriebswirtschaftlichen seite ... und leider, sind da die probleme etwas anders gelagert, als wenn man mal eben als Spass an der freude mal schnell was realisieren will .
4. Was ich ned ganz verstehe ... du willst wrapper schreiben, die auf die MFC aufsetzen, und bindest dich ned an windows ? Willst dann fuer die weiterfuehrung deines Projektes (QT ... etc) die ganzen wrapper neu schreiben ?
5. wir sind uns einig, eine generische Bilblo fuer datenbanken, wo man per lib und mit ner weiteren dll/.so unterschiedliche dbms zulinken kann, waer super. Naja, nur wenn die lib auf der MFC aufsetzt, faend ich ned so gut, am besten waere nur Standard C++ zu verwenden, also die CLibs und die STL.Vielleicht helf ich sogar nen Adapter fuer mysql oder Oracle zu schreiben ...
Ciao ...
-
double post ...
-
tut mir auch irgendwie leid, wenn ich mich zu persönlich ausgedrückt habe. hatte selber etwas stress.
so...
RHBaum schrieb:
2. Ok, mein Fehler, ich hab mir die Site von Sqllite angeschaut, und die einleitung gelesen. Und auch auf paar anderen Seiten die Kommentare zu. Klang fuer mich eher wie ne "einfache" datenbank engine. Wenn man weiter liesst (Asche auf mein Haupt), ok es ist doch eher nen dbms .
zugegeben, das projekt scheint für aussenstehende etwas introventiert zu sein. ich hatte schon vor einem halben jahr den namen irgendwo gelesen, aber konnte damit ehrlich gesagt recht wenig anfangen, geschweige denn es zum laufen zu bekommen.
ich bin dann durch eine antwort auf eines meiner themen im mfc forum darauf aufmerksam gemacht worden. dann dachte ich mir, hey, vielleicht ist es ja doch etwas brauchbares. dann habe ich auf der seite rumgeklickt und die yahoo mailing list entdeckt und dann habe ich die ganze nacht damit verbracht und war sehr überrascht, weil das genau das war, was ich gesucht habe.3. Ich seh die Welt ned nur von seite der Entwickler, sondern auch von der Betriebswirtschaftlichen seite ... und leider, sind da die probleme etwas anders gelagert, als wenn man mal eben als Spass an der freude mal schnell was realisieren will .
bw theorie scheinst du ja studiert zu haben. aber meine erfahrungen sind da auch etwas differenzierter. so habe ich in 2 praktika erleben können, dass software enwickler immer öffters modular arbeiten und eigene schnittstellen schreiben, weil sie halt dann auf den support anderer angewiesen wären, wenn sie z.b. odbc native, also ohne eigene api schicht einsetzen würden. mir wurde gesagt, dass es schon einmal zu einem grossen problem gekommen ist, als eine andere firma den support eingestellt hatte und sie dann vieles umschreiben mussten. (es ging nicht um odbc.) seit dem schreiben sie modular, und haben schon mehrmals einfach andere programme eingebunden, und mussten keine einzige zeile an den anwendungen verändern.
dass diese vorgehensweise geld spart ist in vielen fällen der fall.
ich glaube zwar nicht, dass odbc in der nächsten zeit von der bildfläche verschwindet, aber sicherlich kommt irgendwann wieder etwas anderes. aber in die zukunft sehen kann ich leider auch nicht. nun gut, dieses thema ist für mich nicht sonderlich greifbar.4. Was ich ned ganz verstehe ... du willst wrapper schreiben, die auf die MFC aufsetzen, und bindest dich ned an windows ? Willst dann fuer die weiterfuehrung deines Projektes (QT ... etc) die ganzen wrapper neu schreiben ?
ich will eine wrapper klasse schreiben, die mfc support bietet. und weiter soll will ich sie dann später mit wenigen modifikation (hauptsächlich typen) in eine wrapper klasse mit z.b. qt support umschreiben.
die schnittstelle sollte einfach gleich sein.5. wir sind uns einig, eine generische Bilblo fuer datenbanken, wo man per lib und mit ner weiteren dll/.so unterschiedliche dbms zulinken kann, waer super. Naja, nur wenn die lib auf der MFC aufsetzt, faend ich ned so gut, am besten waere nur Standard C++ zu verwenden, also die CLibs und die STL.
so ein projekt gibt es bereits, kannst ja weiter oben vielleicht nachlesen.
aber es ist zu gross, so viel brauche ich ehrlich gesagt gar nicht.
das ist aber nicht der einzige grund.
dass die bibliothek in c ist, finde ich durchaus sinnvoll. alleine wegen der performance. ich wüsste auch nicht wirklich, was es bringen würde die api in c++ umzuschreiben, denn genau dafür sind wrapper klassen ja ideal. man schreibt sich eine eigene schnittstelle. eine die alles bietet was man braucht, und möglichst wenig kompromisse fordert.
vielleicht ist es ja auch einfach nur eine geschmackssache, aber so wie das jetzt bei mir ist, ist es für mich ideal.Vielleicht helf ich sogar nen Adapter fuer mysql oder Oracle zu schreiben ...
falls du interesse hast bist du herzlich eingeladen!
ich verrate noch etwas... mir geht es im weiteren sinne auch darum, die schnittstelle praktisch anzupassen, und praktisch zu optimieren, und zwar beides aus der sicht mehrerer augen. im grunde würde die schnittstelle ja gleich bleiben, egal ob mit mfc, qt, oder gtk support, ändern tun sich doch nur die jeweiligen typen, die man dann später als anwendungsprogrammierer vor sich hat, wie z.b. CString bei mfc. aber die methoden an sich, ändern sich kaum.
worum es mir sonst geht, ist eine optimierung dieser schnittstelle.
renel hatte mich schon deutlich weitergebracht und ich würde mich freuen, wenn ich aus jeder anderen zusammenarbeit lernen könnte. dieses projekt wird davon sicherlich profitieren.
-
tut mir auch irgendwie leid, wenn ich mich zu persönlich ausgedrückt habe. hatte selber etwas stress.
Wir sind alle nur Menschen ...
bw theorie scheinst du ja studiert zu haben. aber meine erfahrungen sind da auch etwas differenzierter
Naja, in der Praxis entwickle ich Projecte fuer groessere Firmen, die nen Einkauf (als Abteilung) haben, der groesser als ... naja, nen mittelstaendiges Unternehmen ist :p
Klar, mit den produkten "kleinerer" Firmen moegen die Projektleiter ueberhaupt nicht, aus den von dir benannten gruenden. Frei Implementierungen sind noch schlimmer, die kosten zwar nix, aber auf die kann man auch nix abwaelzen...
Aber der Projektleiter wird keinen Moment zoegern auf die Schnittstelle einer Firma mit finanziellen Polster und einer Lizensierung, die keine Haftungen ausschliesst, auszuweichen.(Erst Recht nicht, wenn die Firma in Redmont sitzt). Da kann die Schnittstelle noch so uebel sein ...
Mit "internen" Standards haben wir (auch ich) ... eher schlechte erfahrungen. Die dokumentationen sind eher greulich, auf grund mangelnder zeit geniesen sie auch nie die Prio die sie haben sollten, und wenn die federfuehrenden ueberwachenden kollegen gehen, verwandelt sich der Standard meist innerhalb von kurzer zeit in eine prozedurale Beschreibung des Wahnsinns !
Ne weitere Problematik ist die Kompatiblitaet der kollegen ... es gibt halt Vorlieben.
in 60% der Faelle umgehe ich als Moduleentwickler die Schnittstellen anderer Kollegen und greif lieber auf die DB-Engine direkt zu, weil die Schnittstellen meist ned passen / zu unflexiebel sind. Notwendige Aenderungen auf mein verlangen eh ned gemacht werden, und von den kollegen lieber ueber beziehungen abgeschmettetert oder ausgessen werden.
Wenn jemand Standardisierte Sachen verwendet, kann man meist aufatmen ....Das ist nur meine Erfahrung, in kleineren Firmen ists hoffentlich besser ...
Die Programmierabteilung ab ner bestimmten groesse hat viel oft viel mit ner Behoerde gemeinsam ...Ciao ...
-
denke einfach dass du irrst, wenn du sagst, dass projektleiter sich lieber auf produkte von firmen verlassen, die lizensiert sind. entweder das, oder die projektleiter irren sich gewaltig. denn genau darin liegt doch der trick der redmonder.
kleines beispiel: eine berufscollege in meiner stadt wendet sich direkt an microsoft und wird mit lizensen und einem supportvertrag für 2 server und 500 clients ausgestattet. im vertrag heisst es, dass alle anfallenden wartungsarbeiten, wie updates und reparaturen, von betriebssystemen und anwendungssoftware inklusive sei.
erst bester fall, es kommt ein neuer virus raus und etwa zur gleichen zeit scheint die netzwerkkonfiguration des office produktes nicht mehr richtig zu funktionieren.
auf die supportanfrage bekommt man als antwort, dass solche fälle vom original microsoft support ausgeschlossen seien. man wolle sich doch bitte an einen microsoft partner wenden. dieser macht auch gleich schon einen kostenvoranschlag. auf die anfrage, was denn unter die supportleistungen fallen würde, konnte niemand auch nu eine beispiel nennen.nach wochenlangen diskussionen mit dem support partner konnte man sich einigen. 2,5 % kosten rabatt wurden eingeräumt.
das alleine ist für mich beweis genug, dass die meisten unternehmen heut zu tage ehe nichts von support vertägen halten. und ausserdem, was sollte man in de fall tun? microsoft verklagen? vor gesetz ist der reiche gleicher.
projekt führung hin oder her. bei mir wird es noch sehr lange dauern, bis ich an projekten arbeite, de so lang sind, dass sich normale open source strukturen auflösen können, bevor ich mit diesem projekt fertig bin.
und wenn der projektleiter merkt, dass die stifte, die für die schnittstellen verantwortlich sind, nicht sauber und gut arbeiten, dann würde ich an seiner telle mal ein machtwort sprechen.
vielleicht hast du ja mehr erfahrungen gesammelt. vielleicht habe ich weniger erfahrungen gesammelt. vielleicht hast du aber auch nur etwas einseitige erfahrungen gesammelt. open source kann und darf man nicht werten, schon gar nicht abwerten.
ausserdem, wenn du die schnittstellen in deinem programm umgehst, und die anderen das wahrscheinlich ebenfalls tun, dann würde ich sagen: viel spass beim warten und weiterhin, setzt du damit nicht selber deinen eigenen stil/geschmack durch?im grunde packst du ein und das selbe in verschedenen farben in zwei verschiedene kisten.
ein roter ford ist nicht besser als ein weisser.aber, lass und doch einfach darauf einigen, in einigen fälle ist opensource das bessere, in anderen nicht!
-
Hi!
Nur ganz kurz: Weiß jemand, wie man die Synchronisation von SQLite abschalten kann?? Weil sonst fängt bei vielen Inserts die Festplatte furchtbar an zu rödeln und die Performance geht in den Keller...
-
mit
PRAGMA synchronous=off