A little programming tip for you

[vorapoap (vory)]

This is not to insult you, but I would like to share this knowledge in case that somebody may want to apply and doesn't know about it yet.

Normally, one integer (INT in MYSQL) is consisting of  32 bits.  This bit can be either 1 or 0, hence you can use 32 bits as 32 flags to indicate something that has two status. "On, Off" "True, False" "Enabled, Disabled".. If people don't know about this, they would always use the BIT or BOOL or TINYINT in MYSQL.

How to get it work?
First it is necessary to understand the first bit no. is counted from the right to left.

$status = $mysettings & (1 << $slotno);

Above command is to find the status of bit $slotno in the variable $mysettings. The result can be either 1 or 0 and is returned  to $status.

1 << $slotno

In case of 8bits(it is not!), this thing shifts the 00000001 (or 1 in decimal) to the left for $slotno bits. so if $slotno is 2. the result will be 00000100 (or 4 in decimal) As you can see left shift can be used as a multiplication with 2.  Processing at this level is considered to be the fastest * operator (You can use right shift, too as to divide)...

Ok so now how to toggle the bit in it?

$mysettings |= (1 << $slotno);

Above command will do the OR operator , or in other words to turn the bit on. If $mysetting is 00001101 and $slotno is 1, after the operation $mysetting will become  00001111

To turn it off you need AND operator like this

$mysettings &= (~( 1 << $slotno));

First it shift 1 to the desired bit.,and ~ inverse them all such as 00000100 to 11111011, so whenever you AND this with something, it will like turn the bit no 3 off

For BIGINT, I believe that is 64bits variable type. so you can have 64 slots to use.  TINYINT maybe 8bits.

I recommend programming that heavily relies on flag setting in the relational database to use this. Not just in PHP but in other programming languages too;

I hope this is useful for somebody.
Good luck!

[Myiasis]

I can agree with this for the most part, but I'd like to make some comments on it too.

There is always a tradeoff if you want to pack data like that for how easy code is to read. There is a lot to be said for code that you can understand at a glance. Particularly in an open source community where other people may have to look over your code at some point.

In MySQL BIT is synonymous with a TINYINT which is 1 byte. A decision should be made whether adding the bit operations to your code is worth the legibility trade off of just using a few bitfields. Factors that may help you decide are perhaps how much space you have available and if the data is in a table that will hold a lot of data. If you are going to have a few flags on a table that does not contain, and will not contain, a lot of data, you might be better off keeping your code simple and just using a few bit fields. Disk space is pretty cheap now too -- not that it should be wasted but the concern for conserving it isn't what it used to be. On the other hand, if you have 30 flags and an lot of rows, you might well be better off packing the bits like suggested.

MySQL unfortunately doesn't really treat a BIT field as nicely as it could. Your suggestions do definitely apply here to MySQL more than they might to some other databases. Many database will pack the bits for you and using a BIT field is wise. The database will allocate as many bytes as it needs to hold the bit fields in your table. All of the complexity is removed for you because you still access the BIT fields as their individual column names while the database worries about how those bits map to the actual data. I'm just mentioning this so people don't get the idea that BIT fields are always bad to use in a database, they just aren't as efficient in MySQL as they can be elsewhere.

I'm not disagreeing with your post, just offering up another point of view. I'm a big fan of making code as easy to understand as possible. I work in an environment where I have to read other people's code and they have to read mine and the less complicated the better in most cases.

I do agree that if you have an outrageous amount of flag data in a table that is heavily populated that the trade off of legibility vs. efficiency may be the best route.

[vorapoap (vory)]

Thank you Myiasis

I agree to your post for the most part, and something is new to me too... And I do understand about the readibility of the code. That's why in C they like to define it as a macro, and the compiler will deal with it like an inline command not a separate function. However, in PHP, I don't think such macro exists, so considering using function is a good idea for this.

Just an idea    As we both know this is a controversial trade-off problem.. I once used this bit processing level to deal with N-queen problem and it worked superbly faster ...

 

[Myiasis]

once used this bit processing level to deal with N-queen problem and it worked superbly faster

Yeah, bit operations are fast, I'll give ya that.

C they like to define it as a macro, and the compiler will deal with it like an inline command not a separate function. However, in PHP, I don't think such macro exists, so considering using function is a good idea for this.

Again I agree, making a generic function that would pull the bit off you want and return a true/false represenation would go a long ways towards the legibility of the code.