Re: Why is it wrong to have relationships without an inverse
Re: Why is it wrong to have relationships without an inverse
- Subject: Re: Why is it wrong to have relationships without an inverse
- From: Ian Joyner <email@hidden>
- Date: Mon, 24 Jun 2013 17:52:33 +1000
On 24 Jun 2013, at 02:11, Gordon Apple <email@hidden> wrote:
> You mentioned MacApp. I was heavily involved in that for awhile and even
> got into the credits. I don¹t know if you remember Bob Krause. When I was
> running the developer sig at LA Mac Group, I had him down for a presentation
> on his object database backend, NeoAccess. He had a version for MacApp, but
> I believe he also had one for Next Step.
MacApp - I used to teach it as well. It was good in Object Pascal, but that got me into Eiffel to address the weaknesses of Object Pascal and the type system. But then Apple completely wrecked it by redoing it in C++. I'm still waiting for Eiffel to take off - it's not impossible - my wait for Apple (not Gordon :-)) finally paid off, but I seem to be old enough to be a teacher these days... oh well.
> I tried to get Apple, Inc. to look
> into it, but I guess they decided to go with their Enterprise Objects to do
> CoreData instead. I wish they would take another look and consider doing a
> true object database engine using more of a CORBA-type interface, which, I
> believe, was attempted by Taligent, before Jobs killed it.
Enterprise Objects still is the best ORM around. The others mostly only do either new models or interfaces to legacy models, but not both. WebObjects is still worth a look at, although it was backed into the Java corner.
I can't comment on what you mean by 'true object' database engine, but it is my observation that most OODBs are based on extremely dubious foundations. Any DB really should be based on the relational model (Hmmm IBM got something right along with Fred Brooks), which can be extended with certain OO ideas like inheritance (EO does this rather well). In retrospect, I think Unisys made a huge mistake by not going more strongly with the relational model, although its DMSII could be used as a relational engine (and I did the Transparent Gateway interface to it), it was still rather record-at-a-time. Hammer and McLeod did a version of their Semantic Data Model (SDM) at Burroughs which was adapted to SIM (Semantic Information Manager), which also had inheritance. It was quite nice but didn't really get traction. Doug Tolbert, Randy Guck and others had a paper in Cardenas and McLeod 'Research Foundations in Object-Oriented and Semantic Database Systems'"
http://www.informatik.uni-trier.de/~ley/db/books/collections/cardenas90.html#JagannathanGFTT90
this is not a link to the paper - I can't find one, but here is another paper:
ftp://ftp.cs.utexas.edu/pub/techreports/tr03-43.pdf
I read some of the papers out of that book a few years ago, trying to clarify my thoughts on DBs and came to the conclusion that putting semantics at that level is a bad idea and that the level of semantics in the relational model is correct (although the OO and ER crowd frequently states that the relational model does not include semantics). I think the correct place to put semantics is in the applications - it is too hard (read non-agile) to predict all the possible uses of a DB up front and include it in the DB.
As for CORBA-type interface - that was one of the worst interfaces ever - a complete committee designed C++ mess. CORBA really is dead - the answer is REST. Michi Henning's article in ACM Queue is interesting reading on CORBA's fate.
http://queue.acm.org/detail.cfm?id=1142044
>
> On 6/22/13 2:00 PM, Michael Crawford <email@hidden> wrote:
>
>> I don't use Core Data because it's not cross-platform. In my honest opinion
>> no one in their right mind would bet their livelihood on platform-specific...
_______________________________________________
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