Re: When does one put data into a separate table?

From: paul c <toledobythesea_at_oohay.ac>
Date: Sun, 24 Jul 2005 23:13:31 GMT
Message-ID: <vgVEe.28460$%K2.4707_at_pd7tw1no>


paul c wrote:

> Paul wrote:
> 

>>
>> This is a sort of vague question.
>>
>>
>> Let's say that you have a db with a "personnel" table.
>>
>> Personnel_ID INTEGER PRIMARY KEY,
>> First_Name VARCHAR(30) NOT NULL,
>> Last_Name VARCHAR(50) NOT NULL,
>> add1..
>> add2..
>> add3...
>> tel..
>> mobile...
>> Language1 VARCHAR(25) NOT NULL,
>> Language2 VARCHAR(25),
>> Language3 VARCHAR(25),
>>
>>
>>
>> Now, my question here is when does it become necessary to hive off
>> another table
>> Person_Language
>> ID INTEGER NOT NULL
>> Language VARCHAR(25) NOT NULL
>>
>>
>> The vast *_vast_* majority of people will only speak one or two, a few
>> 3, a couple 4 and very, very few will speak 5 or more. So, let's say
>> we allow 5 fields in the Language part of the table, or even 6 or 7
>> (just to cover the Einsteins).
>> I'm wondering when people would both in theory and/or in practice
>> start to move an attribute like this off into another table? Is there
>> a "Golden Number" above which it automatically gets put into another
>> table, or how do IT professionals decide on such things?
>>
>>
>> Paul...
>>
>>
>>
> 
> here's a vague answer then.  1) be wary of what professionals do as the 
> term only means somebody else has decided to pay them, who knows who and 
> for who knows what reason, and the result may not be very good/useful, 
> which may be why so many professionals seem to be needed. 2) as to the 
> point, i'd say you could try to decide/find out how the language info is 
> going to be used.  for example, if the purpose of one of the languages 
> is to know which to use when communicating with an employee, then that 
> sounds like one 'primary' 'field'.  if the others are there for 
> biographical reasons or to know if somebody can help out in Russia, then 
> you might get away with a single 'secondary/alternate' field.  seven 
> language fields seems a bit much to me.  besides, you might end up 
> deciding that a better way to record language is as an attribute of work 
> people have done in the past, which would possibly be held in one or 
> more different tables than the personnel ones.
> 
> p
> 
> 

sorry, i was more vague than i intended - i meant to say, put all the other languages in one field! if this strikes some as heresy, then maybe they could try deciding how to isolate the components of the home addresses of all those different language speakers!

p

-- 
Apologies for my broken keyboard.  I'm using the keyboard combination 
'kw' to substitute for the broken key that stands for the letter that 
falls between 'p' and 'r' in this alphabet.
Received on Mon Jul 25 2005 - 01:13:31 CEST

Original text of this message