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

On 10 Apr, 14:38, 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

This has just been discussed in the NG!

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.

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

Vladimir Ghetau <vladimir@pixeltomorrow.com> wrote in
<53c1e0fe-e322-45e3-97d6-6c7c772bb557@u69g2000hse.googlegroups.com>:
> On Apr 10, 5:41 pm, ZeldorBlat <zeldorb...@gmail.com>
> wrote:
>> On Apr 10, 9:38 am, Vladimir Ghetau
>> <vladi...@pixeltomorrow.com> wrote:
>> > 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
>>
>> 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.
>
> 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:
>
> group_ID | desc | tags
> ------------------------------
> 1 | null | a,b,c,d,e,f
> 2 | null | c,d,e,u,p,r

You've been told to normalise your schema. This violates
1NF.

--
"...a Netscape engineer who shan't be named once passed a
pointer to JavaScript, stored it as a string and later
passed it back to C, killing 30..." --Blake Ross

On 11 Apr, 08:06, 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

Yes you were talking about the number of columns. I quote:
- a table with more rows, but less information on each row
- or a table with less rows, but more information inside each row

Inside a row you have columns. Insidea column you have data
(information).

The answer is the same as for the other thread. Normalise!

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.

ZeldorBlat wrote:
> 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.


Deja vu. do you guys get the feeling that there is a course out there
handing out this particular homework assignment?

Still people trying to be DBA's that shouldn't even own a computer - let
alone being some sort of admin...