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?


According to the MySQL website (10.1.1)

http://dev.mysql.com/doc/refman/5.0/...-overview.html

BOOL = BIT(1) = TINYINT(1)

And according 10.2, TINYINT is 1 byte. It also says:

"As of MySQL 5.0.3, a BIT data type is available for storing bit-field
values. (Before 5.0.3, MySQL interprets BIT as TINYINT(1).)"

Thanks

On 9/30/2010 10:51 AM, Sgt Snorkel wrote:
32 BOOL columns is not the same as one BIT column with 32 values. 32
columns will take 32 TINYINT's.

But why are you prematurely optimizing? Even if you have 1M rows, the
difference is only 31 MB. Design the database properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On Thu, 30 Sep 2010 15:37:17 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

That's what I thought, thanks.

Because I need to send it from the server to the client over the
Internet. A 32:1 reduction in size is a 32:1 reduction in wait time.

On Thu, 30 Sep 2010 15:37:17 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

PS: Isn't the difference actually 28MB?

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.

On 9/30/2010 4:51 PM, Sgt Snorkel wrote:
No, it isn't. You'll have more than that in protocol overhead.

You're prematurely optimizing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On 9/30/2010 5:10 PM, Sgt Snorkel wrote:
True. But why should the database pack them? That's not what you told
it to do. However, it's immaterial - you should not be shipping the
database files, anyway. You should be taking a dump of the database and
ship it.

But again - you are prematurely optimizing. Design your database correctly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On Thu, 30 Sep 2010 20:17:38 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

Do you ever get tired of knowing what other people need better than
they do themselves? Obviously not.

On 9/30/2010 8:55 PM, Sgt Snorkel wrote:
Nope. But transferring the database files themselves is not supported
for a large number of reasons. Export and ship is.

If you don't want an answer, don't ask a question. And don't come
crying back here when you find your data has been corrupted.

And yes, you are prematurely optimizing. I've seen your type too many
times over the 40+ years I've been programming.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On Thu, 30 Sep 2010 22:12:59 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

Ever heard of the One Note Samba?

On 9/30/2010 11:10 PM, Sgt Snorkel wrote:
Ever heard of "clueless idiot who argues just to make himself look even
more stoopid than he is?". That describes you to a T.

I play the note because it is the right one. You are prematurely
optimizing. And copying the files from one system to another is not
supported, for many reasons. The correct way to do it is to backup the
database and ship the backup.

Otherwise, don't come back here crying when your data becomes corrupted.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================