On Fri, Jul 23, 2010 at 12:35 AM, Peter Hunsberger <peter.hunsber...@gmail.com> wrote: > On Wed, Jul 21, 2010 at 11:13 PM, Howard Rogers <h...@diznix.com> wrote: >> >> On Thu, Jul 22, 2010 at 1:02 PM, Scott Marlowe <scott.marl...@gmail.com> >> wrote: >> >> >> >> >> >> Why on Earth would I want to store this sort of stuff in a bit string?! >> > >> > Because you are manipulating bits and not integers? I guess there are >> > 10 kinds of people, those who like think in binary and those who >> > don't. >> > >> >> I don't know about you, but I find looking at 21205 a darn'd site >> >> easier than staring blankly at 101001011010101!! > > <snip> lots of stuff</snip> > >> > >> > Note you can cast integer to bitstring, but there may be some odd >> > behaviour for sign bits and such. Which is again why I'd use the >> > right type for the job, bit string. But it's your project. >> > >> >> Quoting... >> >> > Because you are manipulating bits and not integers? I guess there are >> > 10 kinds of people, those who like think in binary and those who >> > don't. >> >> Er, no. 21205 is not an integer. It's an encoded bit of magic. >> > > In that case your database design is fundamentally broken. A database > should have content fields that map to the needs of the application. > As you describe your application requirements, that is a bit string > and not an integer. Use bit strings and your application logic is > transparent, obvious and easy to maintain. Use integers and you have > to resort to "magic". As you say, it's your choice, but you came here > looking for advice and the advice you were given is very good.... > > -- > Peter Hunsberger
Hi Peter: It wasn't, as the original poster pointed out, 'advice' that was given so much as personal preference. Had someone said, 'ah, but you see storing your 15 meanings in decimal uses up 5 bytes, whereas a bitstring only requires 15 bits, and over 10,000,000 records, the saving of 3 bytes per record adds up...', then that would be technical advice I could listen to, assess and make a call on. But simply saying "your design is broken... wooooo!" might well scare the children, but doesn't really do anything for me, because I know for a certainty that it's not broken at all. It comes down to this: I can do Boyce-Codd normal form in my sleep (...and falling asleep happens quite frequent when doing it, strangely enough), and have been doing so since 1987. I'm certainly not perfect, but I reckon I can tell from a mile away when one of my designs is "broken", as you put it -and this one isn't. I haven't even begun to describe a scintilla of a percentage point of the design decisions this thing has to deal with, nor the fact that it's been running quite happily in this manner for a good couple of years... so you'll just have to take it from me that there's a room-full of users who can look at code '4097' and know precisely what it means and would be mortified if I suddenly started displaying exactly the same meanings in what, to them, would look like utter gibberish. Unless you, or someone else, can come up with some hard, *technical* facts as to why working with bitstring encodings of meaning is so much better than working in decimal, we're sticking with the decimal representation. I'll buy "you're forever doing implicit casts which are poor performers" or "implicit casts might break in a future release" or "it's costing you three bytes per record" ...or anything else in that vein. But matters of transparency and ease of maintenance are entirely subjective things (about which I sought no advice at all, incidentally), and what works for you on those scores doesn't work for me. Regards HJR -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
