Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456

Introduction to Bitmasking in SQL Server 2005 Expand / Collapse
Author
Message
Posted Friday, December 22, 2006 2:40 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, June 4, 2015 9:27 AM
Points: 216, Visits: 679
Joe you still in the Austin area?




Lee Everest

Post #332641
Posted Friday, December 22, 2006 5:15 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, June 4, 2015 9:27 AM
Points: 216, Visits: 679
Doesn't sound like you are slowing down any. Good. Live longer!

I'll be heading down that way tomorrow, G'town, to Mom's for Christmas. Hope to plow over as many 'horns as possible en route





Lee Everest

Post #332674
Posted Sunday, December 24, 2006 5:32 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 3:34 AM
Points: 3,010, Visits: 2,080
What do you get when you cross a sheep with a bee?

Baa Hum Bug


LinkedIn Profile
Newbie on www.simple-talk.com
Post #332717
Posted Monday, February 12, 2007 6:31 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, February 13, 2007 6:44 PM
Points: 2, Visits: 1
 

Lee,

  I found your article very intriguing.  The idea of bitmasking use hex values is indeed an old technique.  Back when programmers actually cared about memory and disk space; back when you had to.  Today's programmers take this for granted and create bloated programs that cost the end user gigabytes of space and a trip to the local computer shack for more RAM.

  Your article reminds us how to maximize space by representing data in hex format.  Actually reminds me a lot of IPV6 and all the hex values now used in this protocol.  Hex allows us to represent far more data in less space.  Even the authors of IPV4 learned this the hard way.  Now we use Hex for IPV6, Ok lessoned learned.

  Again great article and as far as using a DB for this, who cares? A DB is a data repository key word being data just as the file system (e.g. Windows registry) is used as a repository, or memory (temporary, however it is), and XML.

Fantastic!

- M. Ross

Post #344403
Posted Friday, March 23, 2007 12:21 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, June 4, 2015 9:27 AM
Points: 216, Visits: 679
Thanks Matt. I agree and have come to the conclusion that those not agreeing with the article, or those otherwise opposed to using the relational engine in this fashion, would be the first to store XML, a blob, etc. in the database, but would rather have someone else's engine mask the data to binary. I am simply replacing someone's engine for doing this. This is the what they cannot comprehend or make sense out of. And, as far as I can remember, a binary data type is ANSI compliant regardless of who fashions the binary data which goes into it - a third-party program, .Net, or a programmer/db developer.




Lee Everest

Post #353612
Posted Wednesday, December 5, 2007 1:57 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, July 22, 2015 1:39 PM
Points: 945, Visits: 273
ab5sr (3/23/2007)
... those otherwise opposed to using the relational engine in this fashion, would be the first to store XML, a blob, etc. in the database...


I'd say just the opposite. Those who have issues with storing data in this manner would likely have the same issue with XML in the database and for the same reason. Sure it's possible to do it, but then it's not data anymore. It cannot be queried with SET logic. All the benefits of using a relational database are lost. I suppose if you're okay with that, then Godspeed. I would personally avoid it if at all possible.

It is an interesting article nonetheless. :)
Post #429913
Posted Wednesday, December 5, 2007 2:50 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 12:12 PM
Points: 1,037, Visits: 425
Matthew Ross (2/12/2007)


Lee,

... as far as using a DB for this, who cares? A DB is a data repository key word being data just as the file system (e.g. Windows registry) is used as a repository, or memory (temporary, however it is), and XML.

- M. Ross


Yeah... a database is a place to store data, just like an F-15 is a place to store jet fuel. Sorry, but you don't know what you are talking about.



/*****************

If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek



*****************/
Post #429934
Posted Wednesday, December 5, 2007 5:01 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 7:44 PM
Points: 38,321, Visits: 35,234
Whether I agree with bit-masking in SQL Server or not, I enjoyed the article. Thanks.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #429974
Posted Tuesday, March 25, 2008 12:22 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 12, 2008 1:58 PM
Points: 16, Visits: 81
good article, it will be relevant to folks working with hierarchy ids that need to maintain sibling order.

I think I see why Lee avoided varbinary in the example. It looks like assigning a value to a varbinary, witnessing it's length as n, and then bit masking it against itself can result in it having a length longer than n, even if it (the growth in bytes) wasnt necessary.
Post #474313
Posted Thursday, May 21, 2009 2:29 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, November 26, 2012 8:50 AM
Points: 27, Visits: 150
I can understand why people might not like the idea of storing multiple column values in one encoded field, but it does occur to me that this would be a great technique for passing values in a web app. instead of http://blah.com?field1=1&field2=5&field3=7

Bitmask all the values selected and pass them encoded

http://blah.com?referringData=00bx7f

then decode on the page to values for SQL or whatever.

You get a lot of things here: users can't fish by inserting other values in the POST string; your POST string looks LEE7 (sorry...); you have a shorter POST string.

If you do want to store bitmasked vals in the DB, then your response data could also be de-coded on the client side using Javascript (if this is supported). The downside there is, you can see Javascript in View Source. But, seems like this technique could help speed up data-intensive web applications.

Just my 2 centavos. Sorry it's off-topic, but hey.
Post #721698
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse