Re: Databasing and Cocoa
Re: Databasing and Cocoa
- Subject: Re: Databasing and Cocoa
- From: Erik Hanson <email@hidden>
- Date: Fri, 27 Feb 2004 16:54:23 -0800
On Feb 27, 2004, at 11:05 AM, J Tichenor wrote:
My questions:
-- in designing the database/front end, should I assume that any table
I can split data off onto would also be a good candidate for a custom
class in the application -- ie: one table describes the essentials of
what makes a VFX shot special -- it's name, a link to the people who
are working on it, a description of the shot, the shot's status, etc.
It seems to me best to group essential data about the shot into it's
own table, then create child tables which describe more specialized
information on the shot -- associated costs, it's timecode in the
show, etc.
So, does it also make sense to imagine each table and child table
being an class and subclass of the basic vfxShot type?
What is the standard procedure in designing a database application.
I would write the classes first, then set up the database to store the
information represented by the classes. I'd wait until the last
possible moment before setting up the database since databases can be
tough to change.
I'd also think really hard about whether a SQL-based relational
database is necessary. For example, could you just save all your data
in a file when quitting and reload it all into RAM as objects when
starting up? A gig of RAM is only $200.
I have been writing SQL-based relational database-backed apps
professionally for a little over 10 years now, and my opinion is that
while they are necessary for certain projects, they are sometimes
(often?) used when something simpler and easier to change would have
worked just as well or even better.
--
Erik Hanson
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.