Re: Clues on modeling a really simple concept

"Spike" <fauria_at_gmail.com> wrote in message
news:16d72645-6a6b-4fd4-bccf-d5002970f9ff_at_q2g2000vbr.googlegroups.com...
> Hi everybody!
>
> I'm trying to model a photo gallery, and i have a doubt on how to
> implement it.
>
> I have a table for users. I have another table for pictures. And
> finally, i have a table for galleries (which are sets of pictures).
>
> Both galleries and pictures belongs to a single user, but a single
> picture can be used on many galleries.
>
> So, i have something like this:
>
> users --> pictures --> pictures_to_galleries --> galleries
>
> My question is: Should i add a relationship between galleries and
> users?
>
> I would like to query which galleries a user has, and i don't really
> know if it is worth adding a foreign key rather than doing a three-
> level join query each time i want to obtain this data.
>
> Thank you very much!
>
>

Hm, where to start, where to start...

From your original post and your first responses, I'm guessing that you're a
database neophyte, and that your comments are completely innocent.

If, in reality, you are a troller and are simply trying to stir things up in
this newsgroup, then congratulate yourself on having bamboozled me, and have
yourself a good laugh at my expense. Then go away.

But if, as I'm guessing, you're a database neophyte, then you are likely to
be unaware of the extent of your ignorance of database fundamentals. This
is true even if you're a fairly experienced programmer. Don't try to learn
database fundamentals by trial and error. You'll almost certainly regret
it. Learning database fundamentals by asking questions in newsgroups is
only slightly better than trial and error. You need a good book or
tutorial. My library is way out of date, so I'm going to leave the
recommendation of a good book or tutorial to other responders. I'll just
say to avoid books written for dummies. Dummies should not build databases.
In the meantime, I hope you get some of the answers you need in here.

Other responders have noted that you seem willing to relax the requirements
in order to get decent performance, and they emphatically discourage such an
apporach. I agree with those responders. You're much better off adopting a
firm set of requirements and building a good database that meets those
requirements.

I've got lots more to say, but I'll put that in other responses.
Received on Tue Apr 07 2009 - 13:48:47 CEST