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: Chris Idou <email@hidden>
- Date: Mon, 18 May 2009 18:07:42 -0700 (PDT)
>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