Re: Core Data Abstractions
Re: Core Data Abstractions
- Subject: Re: Core Data Abstractions
- From: "Timothy Reaves" <email@hidden>
- Date: Tue, 31 May 2005 16:55:16 -0400 (EDT)
- Importance: Normal
> On 31/05/2005, at 11:37 AM, T Reaves wrote:
>>> Whereas this would work, it's a nasty hack just to retrieve an
>>> extent (all instances of a particular class). Wanting a class
>>> extent is a fairly common thing, and needing to create and manage
>>> collections manually to help is tedious at best.
>
>> (a) It's a perfectly respectable design pattern, not a "nasty hack".
>
> In fact it's standard practise in relational database design. It's
> called "Normalising". One thing that's often overlooked is that Core
> Data is, in effect, a Relational Database modelling tool, and a whole
> set of different processes and skills are involved in coming up with
> a good relational model than in standard OO design.
>
> Apple don't talk much about this. There are no examples yet, that I
> have seen, that deal with this issue. The best info i have found is
> in 15 year old books on database design process.
>
> Maybe someone can come up with some links and/or article towards
> remedying this conceptual gap for Cocoa developers?
>
> Alex Clarke
> email@hidden
>
>
>
No, that is not called 'Normalizing'. For a definition of
Normalizing see http://en.wikipedia.org/wiki/Database_normalization.
You'll find nothing about adding a table (entity) to track entries in
another table.
As to the loose wrapper around a rdbms, that's not true either. In a
RDBMS world, if I want all instances of an object, I simply execute
'select * from myTable', I do not create another table and add all
instances of the second table to it.
Or more clearly stated, the extra entity mmalcolm refers to IS the
table; I need create no extra db object to track those for me.
It is unfortunate that people can not seem to break free of a
relational / procedural world. Objects work so much better with -
well, objects - then they do with relation tables. Isn't that why OO
languages are chosen over procedural languages?
If CoreData at an implementation level wants to be a thin wrapper -
Hibernate from the Java world if you will - that's (almost) fine, but
hide the procedural stuff from me, and let me play with objects.
I write very large multi-million dollar software systems for very
large fortune 500 companies using Java. Hibernate is very widely used
at the moment because of the promise of using objects and hiding all
the SQL code from your program (Parc estimated that 60%-70% of code in
an OO application & relational db was SQL related). What companies
are finding out is that Hibernate introduces as many problems as it
solves, and makes the developer muck around much more with SQL &
RDBMS' that anyone at first blush believes will be needed. So much so
that there is already a big push away from Hibernate for all but the
smallest applications. I hope CoreData does not go the same way.
_______________________________________________
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