>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%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
