Re: Database
Re: Database
- Subject: Re: Database
- From: Ted Thibodeau Jr <email@hidden>
- Date: Thu, 27 Jan 2005 09:41:21 -0500
* John DeSoi [2005/01/27 12:56 AM -0500] wrote:
> On Jan 25, 2005, at 9:27 AM, Ted Thibodeau Jr wrote:
>
>> (For reasons which pass understanding, Apple didn't choose to
>> include the full kit, which OpenLink provided to them, and only
>> bundled the dylibs + headers. Further confusing the issue and
>> the world of users and developers, iODBC 3.0.6, which has been
>> outdated since before Jaguar shipped, was the version chosen --
>> and remains the version Apple ships. iODBC 3.51.2 is the
>> current build available from the download sites for Mac OS X,
>> with 3.52.1 coming shortly as we gradually update builds for
>> all platforms. If you work with ODBC at all, or with tools
>> which work with ODBC, please let Apple know that you'd like to
>> have the latest kit in both Panther and Tiger environments!)
>
> Unfortunately this is exactly why I try to avoid ODBC. You need
> to have all the right drivers, libraries, and so on and then hope
> for the best if you want to distribute something or move it to
> another machine. I'm sure it is a good approach if working with
> multiple databases is a requirement, but otherwise there are
> much better solutions.
It is my experience that working with multiple databases may not
be an immediate requirement, but in the modern world of mergers
and acquisitions, it is an eventual certainty.
Building one's tool to work with ODBC and standard SQL is an
investment in the future, not only for this eventuality, but
also for ongoing maintenance and support -- as it is always
easier to work with standards-based code than with implementation-
specific code, most especially when one is not the original author
of that code -- and I'm sure most of us have been asked to work
on something of which we had no hand in the original creation.
If nothing else, it is easier to start with spec-compliant code
and convert it to a proprietary implementation, than it is to
start with a proprietary-based code base and convert that to
another proprietary implementation.
I should note -- the iODBC runtimes (Frameworks, dylibs, etc.)
are redistributable. The only component in the OpenLink-branded
SDK (which contains the prebuilt runtimes, as opposed to the raw
iODBC SDK which only contains source code) which is not currently
open source is the OpenLink ODBC Administrator (the Admin which
delivers user-friendly dialogs through use of Setup libraries,
where Apple's proof-of-concept re-implementation delivers only
a keyword=value entry interface) -- and this is slated to be made
open-source, though I do not have an ETA.
>> By using such an agnostic API, which is also cross-platform,
>> you can build your application once, and use it long-term,
>> recompiling to get some platform benefits, but otherwise not
>> worrying about the newest versions of databases or other
>> things.
>
> I'm biased, but PostgreSQL runs on just about every operating
> system (including Windows now with PostgreSQL 8.0). In fact,
> the server protocol is well documented and it is relatively
> easy to build a client/server interface using just TCP/IP
> sockets. Unlike most (all?) of the other databases mentioned,
> PostgreSQL is free for all uses including commercial
> applications.
PostgreSQL is an outlier, no question. PostgreSQL generally
sticks to SQL standards (so if your SQL works with PostgreSQL,
it will probably work with any other standard-compliant DBMS).
However -- PostgreSQL is still a small piece of the deployed
DBMS world, and thus, unless your tool is always going to be
used in a discrete fashion, and there is no need to mix your
data with that of any other department in the organization --
you will find yourself with a need to mix in some way... and
it's more difficult to do that, and make it work, with multiple
ongoing DBMS back-ends, than by unifying the data storage and
adjusting ODBC DSNs.
>> There's lots of saying Prevayler is superior to RDBMS,
>> restating the same thing over and over again, but not a
>> lot of information about how it works, nor real-world
>> examples.
>>
>> I'd like to see some TPC-style testing comparing Prevayler
>> to the RDBMS paradigm, and some discussion of non-Java
>> solutions, rather than just the hand-waves there currently...
>
> I think there are some uses for the idea, but not as an
> enterprise database replacement.
>
> Some work has been done in this area with Lisp.
> See: http://common-lisp.net/project/cl-prevalence/
> and a real-world application study:
> http://homepage.mac.com/svc/RebelWithACause/
Object Prevalence is certainly a valuable concept to explore, but
the Prevayler project, as presented on its wiki site, doesn't seem
to match up very well with the theory or discussion of the basic
theory. Suggested uses don't tie in with actual capabilities of
the available implementation source code.
Still, as noted by Carlos Villela in my earlier posted quote, it
does have some definite points of utility -- but it was never
meant to be a DBMS replacement, and suggestions that it should
be are troublesome.
Interesting stuff.
Ted
--
A: Yes. http://learn.to/attribute
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?
Ted Thibodeau, Jr. // voice +1-781-273-0900 x32
Evangelism & Support // mailto:email@hidden
OpenLink Software, Inc. // http://www.openlinksw.com/
http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs http://www.openlinksw.com/weblogs/virtuoso/
http://www.openlinksw.com/blog/~kidehen/
Universal Data Access and Virtual Database Technology Providers
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Database (From: Carlos Coutinho <email@hidden>) |
| | >Re: Database (From: Ted Thibodeau Jr <email@hidden>) |
| | >Re: Database (From: John DeSoi <email@hidden>) |