Re: Databases on Cocoa (was Re: Invoice program made in Objective c/Cocoa)
Re: Databases on Cocoa (was Re: Invoice program made in Objective c/Cocoa)
- Subject: Re: Databases on Cocoa (was Re: Invoice program made in Objective c/Cocoa)
- From: Robert Martin <email@hidden>
- Date: Mon, 18 May 2009 21:44:18 -0400
If you're trying to say what you think CoreData 'should' be - then
take it up with Apple. (which is not this list, by the way)
This whole thread is depressing. Is anyone out there who is trying to
say that CoreData should be an object database capable of reading the
docs? If so, what part of the documentation is confusing you? The part
that makes you think that CoreData is an object database, for example,
is specifically what?
On May 18, 2009, at 9:07 PM, Chris Idou wrote:
Core Data solves that through the use of a SQLite backing store.
SQL based data storage is the standard means of achieving
incremental retrieval
and storage of data in our industry.
If Core Data talked to standard databases like Oracle etc, then I
can see that as a selling point. But since it doesn't, and since it
tries to hide SQLite, it's hard to see how it is much of a selling
point. That SQL is pervasive is irrelevant if you're hiding the
existence of SQL. If you're going to make it look like an object
database, but not talk to widely deployed SQL databases, then you
really should make it an object database. I don't know how core-data
handles inheritance, but all the ways of doing it with an SQL
database make performance suck if you want to do anything serious,
and they also make writing SQL queries intractable if one wanted to
get some benefits of having an SQL back end. I guess some people
don't want to use any inheritance because their problems are simple,
and it *can* work for them, but having a proper object database with
a query facility or SQL front to it could work for them too.
We're in an object world now, and SQL databases can't cut it for
many many problems. Accounting style applications, yes they *can*
work. But there are vast areas of computing where its just too
inefficient. Goto the web site of an object database like Versant
and look at the wide variety of customers they have. They don't buy
it because they are geeky, but because SQL databases can't do it.
At that point, the choices are to fully document the schema and
implement a whole bunch more code that tries to detect when someone
has done
something wrong in the database. Combined with the need to
provide some kind of a means of making access to many different
vendor's databases
transparent -- some of which have notoriously "odd" implementations
of the SQL spec -- make implementing (3) extremely costly both in $$
$ and
engineering hours spent.
It's not *that* hard. Java tools like Hibernate do it. They still
have the sucky performance implied by mapping object graphs to
relational databases, but it at least gives you the ability to talk
to any SQL database you want to, while still having a core-data like
object access. Anybody else looking for an interesting project to
work on could well port Hibernate to objective-c.
In the case of (3), the assumption would be that -- like with the
SQLite database -- Core Data would manage the entire schema of the
database on
the server. Certainly, that would be useful to a subset of
developers, but how many? In studying the problem, I come up with
"not that many". In
almost cases where I have looked at problems that required client/
server database access, one of the requirements was to interface
with some kind
of a reporting engine, web service/server, or something else that
wants to go trolling through the data store and, more likely, edit
stuff.
Nobody wants multi-user access unless they can interface with some
3rd party report engine? Firstly, that's not even nearly true. Tons
of companies are buying object databases, and a relatively small
group of them actually use them with reporting engines. Secondly an
object database has the ability to upload object schemas derived
from the object source code to a server without any difficulty. This
is easy stuff for an object database. Thirdly, any decent object
database can offer a legacy SQL interface that 3rd party reporting
engines can talk to.
So that brings up (4). (4) is a really really really hard problem
to solve.
It's not even an issue for object databases, and it's not *that*
hard to solve for SQL databases as Hibernate shows.
Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http://au.rd.yahoo.com/mail/tagline/creativeholidays/*http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=mailtagline
_______________________________________________
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