On Wed, Jun 27, 2007 at 10:32:29AM -0500, [EMAIL PROTECTED] wrote:
> > > Sadly, that is the way we had it, we decided to switch to using the
> > > owner flag to try to eliminate duplication of data in the database.
> >
> > False economy - that isn't duplication, as the first reply to the this
> > post points out. Won't work the way you've got it, we don't tend to add
> > code to make broken database layouts easier to core.
>
> True, but what if you have properties about the relationship that reflect
> the many to many map directly? ignore one-owner-per-picture, and suppose
> you have a set of data such as preferences that are directly related to the
> many-to-many relationship between user and picture. Is the mapping table
> not the correct place for this data? Most of the database schemas I have
> seen over the year would place this relationship modifying data in the
> user_picture mapping tables. What is your view on this? make another
> table that stores the preferences? Am I mistaken that this is pretty
> "normal" database design?
I'd implement that with the has_many + prefetch + proxy approach I suggested
in my original reply in this thread - which was based on the mistaken
assumption that what the OP was doing was what you just described :)
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
