RE: Bitwise comparison -- consider not getting bit

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Bitwise comparison -- consider not getting bit

Griggs, Donald
 Regarding:
    "...What's the best way to do a bitwise comparison in a sql query...?"

Hi Debra,

Dennis Cote gave you a direct answer to your question -- since sqlite
supports bit operations directly in SQL.

But I wondered if you might want to evaluate dispensing with bit-wise
variables and using a more standard SQL approach -- a field for each
variable.

Even with the slightly bigger database, I should think table scans will be
faster, and if an index on one of these fields is ever called for, it will
be trivially easy to add.

You might find that, (unless you're writing an embedded tiny app) even with
many records in the database, only a very few pennies worth of additional
disk space would be required.

Increased portability and easier debugging are other bonuses.  E.g. Imagine
the blank stare you might encounter when you say, "Oh yes, it's easy for you
to run queries on the database for importing into your spreadsheet -- just
parse out the bit flags per our source spec."


Donald Griggs


Opinions are not necessarily those of Misys Healthcare Systems nor its board
of directors.


-----Original Message-----
From: debra f [mailto:[hidden email]]
Sent: Monday, October 03, 2005 12:10 PM
To: [hidden email]
Subject: [sqlite] Bitwise comparison

Reply | Threaded
Open this post in threaded view
|

Re: RE: Bitwise comparison -- consider not getting bit

de f
Thx for the opinion.  Will consider it!



---- On Mon, 3 Oct 2005, Griggs, Donald
([hidden email]) wrote:

>  Regarding:
>     "...What's the best way to do a bitwise comparison in a
sql query...?"
>
> Hi Debra,
>
> Dennis Cote gave you a direct answer to your question -- since
sqlite
> supports bit operations directly in SQL.
>
> But I wondered if you might want to evaluate dispensing with
bit-wise
> variables and using a more standard SQL approach -- a field
for each
> variable.
>
> Even with the slightly bigger database, I should think table
scans will be
> faster, and if an index on one of these fields is ever called
for, it will
> be trivially easy to add.
>
> You might find that, (unless you're writing an embedded tiny
app) even with
> many records in the database, only a very few pennies worth of
additional
> disk space would be required.
>
> Increased portability and easier debugging are other bonuses.
E.g. Imagine
> the blank stare you might encounter when you say, "Oh yes,
it's easy for you
> to run queries on the database for importing into your
spreadsheet -- just
> parse out the bit flags per our source spec."
>
>
> Donald Griggs
>
>
> Opinions are not necessarily those of Misys Healthcare Systems
nor its board

> of directors.
>
>
> -----Original Message-----
> From: debra f [mailto:[hidden email]]
> Sent: Monday, October 03, 2005 12:10 PM
> To: [hidden email]
> Subject: [sqlite] Bitwise comparison
>
>
>


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag