Re: Multi DB Library
Re: Multi DB Library
- Subject: Re: Multi DB Library
- From: dreamcat7 <email@hidden>
- Date: Wed, 17 Sep 2008 17:39:18 +0100
Hi,
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/
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).
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.
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 ?
On 17 Sep 2008, at 16:26, Ted Thibodeau Jr. wrote:
Can anyone suggest a multi Database library for use in developing a
Cocoa based app? At least support for Oracle, MySQL and PostgreSQL
would be required.
I notice that Python has good database support. Would developing a
PyObjC app be a better way to go?
ODBC... If you're working with any C-based tools, that is. Perl,
Python, Ruby, PHP, etc. -- they all have ODBC libraries.
JDBC, if you're working with Java-based.
Use ODBC/JDBC and SQL standards-compliant calls -- avoid DBMS-specific
dialect -- and you should find that things go pretty well. Changing
DBMS is in all these cases just a matter of changing the ODBC DSN or
JDBC URL -- and of course, having the relevant driver in place.
For full Cocoa ODBC support, you'll need to either build from source
or download a pre-compiled set of the iODBC Frameworks, as Apple has
chosen to only ship the dylibs. < http://sf.net/projects/iodbc>,
<http://iodbc.org/>, or
<http://download.openlinksw.com/download/product_matrix.vsp?p=f_db&fm=1&fam=7&of=5
>.
I will observe that free drivers are often worth what you pay for
them, with incomplete and/or imperfect implementations of some API
calls, but there are plenty of options out there.
(I work for one driver vendor, OpenLink Software, which also happens
to be the maintainer/supporter of the open source iODBC Project, which
is the basis of the ODBC libraries on Mac OS X. We don't make any
money until/unless someone chooses to buy one of our drivers -- the
iODBC SDK is free in all ways, and all our drivers and other
commercial
products have free download and 14-day (renewable) testing licenses,
and free up-and-running support; upgrading to permanent license only
requires a new license file. )
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
_______________________________________________
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