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 |
|
aiken
Aged Yak Warrior
525 Posts |
 Posted - 2002-06-22 : 13:21:05
|
| I've building an app that's going to need to have 16 yes/no attributes for documents. That number is fixed, and it is very unlikely that there will ever be any more attributes.For the sake of simplicity, I've been thinking of just using 16 bit fields in a row. However, that's a pain in the butt to write SP's for and to use in general, and it wouldn't be indexable.What would folks think about using an INT, where each bit is represented; i.e. 1025 would be 100000001? That INT would be indexable, so for exact match searches, it would be quite fast (for inexact matches, it would mean ANDing the int with an int made up of the searched attributes).Am I just reinventing the wheel and doing things the hard way? Should I just be using a table of attributes and a join table against the table of documents and the attributes table? Thanks-b |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2002-06-22 : 20:33:25
|
| >> That number is fixed, and it is very unlikely that there will ever be any more attributes.Really?>> so for exact match searches, it would be quite fastBut for checking an individualy bit it won't.I would include another table withrec_idAttribute_idvalue==========================================Cursors are useful if you don't know sql.Beer is not cold and it isn't fizzy. |
 |
|
|
|
|
|
Best way to have indexable attributes?