Re: Multi DB Library
Re: Multi DB Library
- Subject: Re: Multi DB Library
- From: "Ted Thibodeau Jr." <email@hidden>
- Date: Wed, 17 Sep 2008 15:35:59 -0400 (EDT)
- Importance: Normal
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@hidden)
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:
This email sent to email@hidden