Re: Why is it wrong to have relationships without an inverse in Core Data?
Re: Why is it wrong to have relationships without an inverse in Core Data?
- Subject: Re: Why is it wrong to have relationships without an inverse in Core Data?
- From: Ian Joyner <email@hidden>
- Date: Mon, 24 Jun 2013 11:51:27 +1000
Thanks for the reference to Codd's early paper. I'm researching the relational model now since I'm giving a course in distributed systems soon. In fact, I'm reading Codd's 1990 book "The Relational Model for Database Management Version 2". It is available as a pdf (although I have had the physical book for years. Also good are any C.J. Data writings.
"An Introduction to Database Systems" says "SQL is not perfect. SQL is very far from being the perfect relational language - it suffers from numerous sins of both omission and commission". In particular it allows duplicate rows which lead to anomalies. It is a shame the relational model has come to be judged by SQL (rather like one could judge OO by C++). While Codd was a researcher at IBM, SQL was done by a committee at IBM, and is fundamentally tasteless. SQL also breaks the terminology and confuses tables with relations.
Codd 1990 has chapter 23 "Serious Flaws in SQL".
Other models have come along, like Entity-Relationship (ER) and OODBs, supposedly addressing the 'weaknesses' of relational. But they fail for all their heavy marketing. OO really gets back to network and hierarchical data models. It is also record-at-a-time oriented which was the pre-relational approach. This makes applications and users far more dependent on the structure of the data. While the relational model well expresses semantics, building in too much semantics is a mistake and makes what you might think of tomorrow more difficult because you built today's assumptions into the model. The approach of Hammer and McLeod (which resulted in Unisys SIM, which seemed a good idea at the time) really failed.
ER distinguishes entities and relationships. However, relationships are just modelled by the single notion of relation. For example, 'marriage' is a relationship between two people, but this is just as well modelled by a relation as an arrow between two people in the people relation. You can also add extra information like date-of-marriage and date-of-end, reason-for-end, etc in a relation, which you can't to an arrow. ER is imprecise in these matters. Codd covers this well in chapter 30 and Date in chapter 14. ER diagrams can be useful, but we should not confuse diagrams with goodness, especially when they lack formality (like UML).
Another book available for free online is Hugh Darwen's:
http://bookboon.com/en/an-introduction-to-relational-database-theory-ebook
He has done a lot of writing with Date on marrying relational with OO the correct way (The Third Manifesto).
Perhaps all this answers the original "inverse relationship" question by saying relational doesn't have relationships other than by relating data values. That is there are no rat's nest pointers making the system brittle. I'd have to do some more thinking as to whether that is a weakness in CoreData or not, but it seems to be erring in the ER direction.
On 23 Jun 2013, at 11:04, Michael Crawford <email@hidden> wrote:
> Relational Databases and Databases in general are two different things.
>
> E. F. Codd proposed Relational Databases in a 1970 Communications of
> the ACM paper that turned up instantly in a search. Here's a PDF:
>
> http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
>
> That paper itself says nothing at all about SQL, which is used to
> communicate between the database and either the end user, or software
> that acts on behalf of the end user. Instead it discusses the logical
> structure of Relational Databases, with only databases that have that
> certain kind of structure being considered "Relational".
>
> Part of that, for example, is the notion that there should be only one
> copy of any given item of data. Say you stored Steve Wozniak's
> payroll information, and you put his salary in two different fields
> because it was convenient to do so, either because the client code was
> easier to write, or the data could be retrieved or stored more quickly
> that way.
>
> Inevitably some innocuous error would result in the two copies
> becoming different from each other, and there would be Hell to pay.
>
> There's a lot more to it than that.
>
> Codd himself many years later - just a few years ago - spoke of his
> great disappointment with SQL, pointing out that SQL all by itself
> does not make any database at all Relational. That's up to the
> database architect who designs its schema. There are some things that
> the database vendors must implement, such as atomic and fault-tolerant
> storage, but any fool can create an Oracle or MySQL database that's
> not Relational by designing the tables, rows and columns in some
> manner of incorrect way.
>
> There are many kinds of databases that are really great, but that
> don't even attempt to be Relational.
>
> Mike
>
> On Sat, Jun 22, 2013 at 3:03 PM, Charles Srstka
> <email@hidden> wrote:
>> On Jun 22, 2013, at 10:43 AM, 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 document formats, no matter what the platform.
>>
>> ...
>>
>>
>> While one can use SQLite or XML for the storage, if the SQLite or XML
>> documents are to be opened on some other platform, one would have to
>> write all that code from scratch, without the use of Core Data.
>>
>>
>> To me, it's not that you'd have to write all the code from scratch that
>> makes Core Data concerning, it's the fact that the format is undocumented.
>> Sure, it's not too hard to study the XML or SQLite that Core Data generates
>> and figure out its format, but if there are corner cases in the format that
>> you didn't figure out or if the format changes at some point, any custom
>> code for reading, or especially writing, your format will be buggy and
>> unreliable.
>>
>> If Apple published a complete specification for the format, I'd be willing
>> to use Core Data, but as it is, the prospect of having one's own file format
>> as a black box is a huge turn-off to me.
>>
>> Charles
>>
>
>
>
> --
> Michael David Crawford
> mdcrawford at gmail dot com
>
> Custom Software Development for the iPhone and Mac OS X
> http://www.dulcineatech.com/custom-software-development/
> _______________________________________________
>
> 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