Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Lumbago
Norsk Yak Master
3271 Posts |
 Posted - 2004-12-28 : 10:11:10
|
| Fellas,as I'm going along developing our production website more and more attributes are required in our users-table to keep up with business demands. Are there any implications I should consider when adding more and more columns? Right now my users-table has about 60 attributes and every now and then a few more are put in there. I can't see any problems with it, I'm just curious. I find it sort of useless to create a new table with a 1-to-1 relationship...Any insights people?--Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
|
|
nr
SQLTeam MVY
12543 Posts |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2004-12-28 : 10:49:44
|
| Thanx for the links! However I was more curious about the logical part of it, is it considered bad design to just pour in with attributes that has nothing to do with eachother except for the fact that they are related to the primary key of that table on a 1-to-1-basis?--Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
 |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2004-12-28 : 11:07:00
|
| Nope that's what the pkk is for.If you separate them into different tables you might do it via those that are updates frequently and those that are more static or by the way they are retrieved.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2004-12-28 : 11:17:49
|
| Ok, thanx bro... :)--Lumbago"Real programmers don't document, if it was hard to write it should be hard to understand" |
|
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2004-12-28 : 12:01:17
|
| I would personally seperate the core table with the columns that are pre-defined and constant and that are required for your app to work properly, from the user-defined attributes table, if you haven't already.- Jeff |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2004-12-28 : 12:25:45
|
| You could have a table to define the attributes so you can add them without changing structure.Will be a bit slower to get the attributes but...user_attribute(user_id ,attribute_name ,value ,fk to user_attribute_def)user_attribute_def(Attribute_name ,Attribute_desc ,)==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2004-12-28 : 12:57:33
|
| We have some attributes on rows in a "users-type-table" in one of our applications which are binary.1=Paid, 2=Expired, 4=Reminder sent ...that type of thing. The application handles the binary manipulation, so we just have a suitably-sized INT/binary column in the database. The application can utilise addition attributes (provided they don't exceed the column size)On that tack, if you have BIT fields they are all aggregated together into the minimum number of bytes needed to store them. That's assuming that your attributes are BIT fields, of course.Just my ramblings ... :-)Kristen |
|
|
|
|
|
|
|
|
Column "limitations"