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 |
|
sth_Weird
Starting Member
38 Posts |
 Posted - 2014-09-26 : 06:21:08
|
| hi,I have to design a new table. In this table I need to store some flags. At the moment there are 14, new flags may come at some time, but the number of flags will never exceed 32 and definitly not 64. I thought about using a (big)int datatype and store the flags like that. In MySql there even seems to be a datatype with extra support for that ("SET"). I'm using SQLServer 2012 there does not seem to be a datatype like that, is there?My table will only contain 20-50 rows and I do not intend to do something like "Select all rows where bit x is set". The individual bits will never be part of any query, they will always be seen as a plain number (the programme using the data will do the interpretation).I googled a bit, a lot of people think storing flags as int is the wrong approach, and it's better to have additional tables for the flags and combine the main data to those flags (n:m relationships), but the main reason they give for that is always that it would be hard to query the int column when you want to filter the results based on a certain flag, and (in addition to that) time issues when there are a lot of rows. Well, as I said before, I don't intend to interpret the flags in any query.So, are there any other reasons for not using the int approach? Because right now I simply feel that creating extra tables is a lot of overhead with no benefits in my case at all. But maybe I'm missing something?thx for advice, and please excuse my bad english, I'm no native-speakersth_Weird |
|
|
|
|
|
|
|
Way to store flags (SQLServer 2012)