dreamcat7 wrote: > As a developer I aswell am finding it hard to evaluate these > options myself and without prior experience. For example I > would be drawn to the prospect of learning the same api for > both the local and remote database. (typically id like to > cache the data downloaded from the data onto a local sqlite > DB). I did find only one ODBC driver for sqlite > > http://www.ch-werner.de/sqliteodbc/
That's a good build of the open-source driver associated with the SQLite project. There is also at least one commercial driver for SQLite available for Mac OS X, which you should be able to find through a quick Googling. > Which assuming (enough of it) should work would your comments > still hold? It is was the only Sqlite ODBC driver i could find > so i am inevitably wondering if thats a bad sign to use ODBC > actually as an SQLite interface. And actually how big an > advantage would it be to learn things the first time as the > ODBC way only? (rather than starting with the SQLite C api > which is what others on this list have recommended). Whether either of these offerings support enough of the ODBC API, with few enough bugs or other limitations, can only be judged by you -- it depends on the tool you want to build, and what it will be used for. Learning the ODBC way means that you can take what you learn and apply it to tools you write later, for use against Oracle or MS SQL Server or Informix or Ingres or PostgreSQL or MySQL or ... and the tools you write now will *also* be usable against these other DBMS engines. Learning the SQLite API means that you can take what you learn now and apply the *theory* but far less of the *practice* to such other engines -- and none of the *tools* you build will be usable against those other engines. > And, apologies if this is heading off - topic but > > My other option up to now is to use a special cocoa library for > the SQLite, and something rather different (MYSQL+PHP) on the > server side. This is probably a common question: It actually > simpler then to go MYSQL -> ODBC -> PHP rather than MYSQL -> PHP > for such the benefit of doing "everything" in ODBC. Well, I can tell you that the same person who primarily maintains the iODBC Project has recently been handed the reins for the PHP ODBC libraries -- as we contributed a large chunk of code to that project recently, fixing a number of long-outstanding issues. As above, if you learn how to do things with PHP+ODBC, it won't matter whether the data repository behind it is MySQL or Oracle or otherwise. If you learn to do things with PHP+MySQL, it will matter -- for more reasons, actually, because the MySQL-specific SQL dialect comes into play sooner, and the way you do things within PHP is likely to be different (though it doesn't *have* to be different). > If i understand from your comments then using this API will > conceal differences between MYSQL and SQLite and help me to > concentrate on learning a simple generic SQL syntax. But > bearing in mind the server-side code cant be written in Cocoa > (objective-c) and in my own circumstance it will be inevitably > written in PHP. Do we really end up with a more coherent > environment (fewer languages) to work on our data model which > likely must be transactional with the client ? Yes, I firmly believe you're better off working with open standards and specifications such as ODBC, SQL-9x/200x, JDBC, and others, than you are working with DBMS- or otherwise-specific dialects. As soon as you start working with a specific dialect, you've taken on a degree of lock-in to that dialect's source -- and that can be an enormous burden over time. Certainly, sometimes it's not a burden at all -- but more often than not, it's really just a matter of when, not if, that burden makes itself known. Be seeing you, Ted _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
