Matt S Trout <[EMAIL PROTECTED]> wrote on 06/27/2007 11:24:21 AM:
> 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 :)
>
Gotcha, great -- I was reading too much into your db restructure advice
later in the thread then.
-Wade
_______________________________________________
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]/
