On Apr 11, 3:06 am, Vladimir Ghetau <vladi...@pixeltomorrow.com>
wrote:
> On Apr 10, 5:41 pm, ZeldorBlat <zeldorb...@gmail.com> wrote:
>
>
>
> > On Apr 10, 9:38 am, Vladimir Ghetau <vladi...@pixeltomorrow.com>
> > wrote:
>
> > > Hi guys,
>
> > > Which of the following approaches would you prefer when designing a
> > > database?
>
> > > - a table with more rows, but less information on each row
> > > - or a table with less rows, but more information inside each row
>
> > > I'm doing benchmarks, and trying to approach the problem in different
> > > ways, but I also want to hear some opinion, maybe backed up by some
> > > arguments
>
> > > Thank you,
>
> > > Vladimir Ghetau
>
> > As the Captain pointed out this was discussed very recently. Here's
> > the short answer:
>
> > 1. Normalize your tables.
> > 2. If they have more rows than columns then that is the correct
> > answer.
> > 3. If they have more columns than rows then that is the correct answer.
>
> Hi guys,
>
> Thanks for your answer, but I wasn't saying anything about the number
> of columns, let's explain the problem a little bit more, say we have
> these two tables:
>
> a)
>
> group_ID | desc | tags
> ------------------------------
> 1 | null | a,b,c,d,e,f
> 2 | null | c,d,e,u,p,r
>
> or table b)
>
> tag_ID | group_ID | tag
> ---------------------------------
> 1 | 1 | a
> 2 | 1 | b
> 3 | 1 | c
>
> So basically, I can:
>
> a) either have all the tags in a single row of the tags column (see
> table a), or
> b) I can put each tag on it's own row, and search for tags this other
> way (see table b)
>
> What would you go for and why?
>
> Thanks,
>
> Vladimir Ghetau

If you follow my previous advice then A isn't even an option.