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