Board index » delphi » VarChar and normalisation

VarChar and normalisation


2005-08-29 09:25:54 AM
delphi102
I have a fast growing table which currently has over 1 million records in
it. About 25% of these records require a varchar(50) field, which cos of my
"old school" training I'd normally place in a second table.
My question is, is this really necessary in an SQL environment? Can the
field be added to the main table without signficant "space drain"?
Thanks in advance
Naively
Russell.
 
 

Re:VarChar and normalisation

Quote
I have a fast growing table which currently has over 1 million records in
it. About 25% of these records require a varchar(50) field, which cos of
my
"old school" training I'd normally place in a second table.

My question is, is this really necessary in an SQL environment? Can the
field be added to the main table without signficant "space drain"?
IMO, it is not about space, it is about relational design.
If the field is not a required field, put it in another table.
--
With regards,
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
www.upscene.com
Database development questions? Check the forum!
www.databasedevelopmentforum.com
 

Re:VarChar and normalisation

Russell A writes:
Quote
My question is, is this really necessary in an SQL environment? Can
No, it is not necessary for performance or space reasons.
Quote
the field be added to the main table without signficant "space drain"?
There will be no significant space drain. IB uses run lenght
compression on CHAR and VARCHAR fields with a length of 128 so your 50
character field will take two bytes if it is empty.
--
Bill Todd (TeamB)
 

Re:VarChar and normalisation

Quote
I have a fast growing table which currently has over 1 million records in
it. About 25% of these records require a varchar(50) field, which cos of my
"old school" training I'd normally place in a second table.

My question is, is this really necessary in an SQL environment?
No, just the contrary - unused short varchar field will be easily compressed;
but if you would place this field in separate table, it would cause significant
space drain because each row needs to store some additional internal informations.
Ivan