 | |
Datatypes: BOOL v BIT(1) v TINYINT(1)
comp.databases.mysql comp.databases.mysql
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Datatypes: BOOL v BIT(1) v TINYINT(1) -
10-01-2010
, 10:43 AM
|
If I create a table with 32 columns each declared as BOOL, will the data be stored as bits (32 bits = 4 bytes) or an individual bytes? Will each row be 4 bytes or 32? |
Not saying that what you are doing is wrong, but I have never
encountered such situation, and I'm therefore curios what problem you
are trying to solve.
/Lennart
[...]
#12
| |||
| |||
|
|
On 2010-09-30 16:51, Sgt Snorkel wrote: If I create a table with 32 columns each declared as BOOL, will the data be stored as bits (32 bits = 4 bytes) or an individual bytes? Will each row be 4 bytes or 32? What is it that you are trying to model using a table with 32 booleans? Not saying that what you are doing is wrong, but I have never encountered such situation, and I'm therefore curios what problem you are trying to solve. |
There are a number of collections of these tokens. Each token is in
one or more of these collections. Each BOOL column corresponds to one
of these collections. A "1" indicates that that token is in that
collection. A "0", not. I'm not using a junction table for this
many-to-many relationship because the table is at least 50% and
probably up to 80% full (ie, not sparse).
I am going to do arithmetic on the boolean values and other attributes
of the collections.
#13
| |||
| |||
|
|
PPS: I'm surprised that the database system doesn't pack 32 BOOL columns into 4 physical bytes so I don't have to worry about it. |
a VARCHAR between the 5th and 6th BOOL if you pack them.
Well, actually DOING that wouldn't be that hard, but abstracting it and
then autogenerating code to handle moving the data around for ALL
combinations of types DOES get complicated.
--
62. I will design fortress hallways with no alcoves or protruding
structural supports which intruders could use for cover in a
firefight.
--Peter Anspach's list of things to do as an Evil Overlord
#14
| |||
| |||
|
|
On Thu, 30 Sep 2010 14:10:41 -0700, Sgt Snorkel wrote: PPS: I'm surprised that the database system doesn't pack 32 BOOL columns into 4 physical bytes so I don't have to worry about it. It gets complicated as all hell when you decide to ALTER TABLE and stick a VARCHAR between the 5th and 6th BOOL if you pack them. Well, actually DOING that wouldn't be that hard, but abstracting it and then autogenerating code to handle moving the data around for ALL combinations of types DOES get complicated. |
as my columns?
#15
| |||
| |||
|
|
On Sat, 02 Oct 2010 01:55:03 GMT, "Peter H. Coffin" hellsop (AT) ninehells (DOT) com> wrote: On Thu, 30 Sep 2010 14:10:41 -0700, Sgt Snorkel wrote: PPS: I'm surprised that the database system doesn't pack 32 BOOL columns into 4 physical bytes so I don't have to worry about it. It gets complicated as all hell when you decide to ALTER TABLE and stick a VARCHAR between the 5th and 6th BOOL if you pack them. Well, actually DOING that wouldn't be that hard, but abstracting it and then autogenerating code to handle moving the data around for ALL combinations of types DOES get complicated. Is there any reason that the physical data has to be in the same order as my columns? |
together: To save space for performance reasons. The whole point of
*having* a DBMS though is to *explicitly NOT have to pay attention to
this kind of crap*. If you want to control everything about how
something is stored, C provides ample primitives to manage this.
--
40. I will be neither chivalrous nor sporting. If I have an unstoppable
superweapon, I will use it as early and as often as possible instead
of keeping it in reserve.
--Peter Anspach's list of things to do as an Evil Overlord
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.