On Thu, Sep 18, 2008 at 04:58:35PM +0300, Nick Shaforostoff scratched on the wall: > Hi. I'm deciding between having several INTEGER fields and only one, > which is a bit combination (i'd access it using e.g. main.bits&0x0011, > main.bits&0x0100 and so on). > > The docs say "INTEGER. The value is a signed integer, stored in 1, 2, > 3, 4, 6, or 8 bytes depending on the magnitude of the value." > So: which value is used to determine magnitude?
The value you pass via INSERT. 43 takes one byte. 243 takes two (signed). 90435 takes three, etc. Each individual row/element is custom sized. > Will the database size be larger if I use several fields (containing > numbers smaller than e.g. 255) instead of a one bits field? If you're bit-packing at something less than the byte level, then clearly more fields is going to take more space. Additionally, there is some small amount of space required to designate each column in a row. So overall, yes, the individual fields are likely to be a bit larger. However, depending on what you're doing with the data, chances are the multi-column format is going to be much more useful (and faster) in nearly every other way. You can't put an index on the middle 5 bits of an integer field, for example. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
