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 <cocoa...@charlessoft.com> wrote: > On Jun 22, 2013, at 10:43 AM, Michael Crawford <mdcrawf...@gmail.com> 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
