Data type "indicator" - What about boolean?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Data type "indicator" - What about boolean?

Fabian Gorsler
Hi,

a new day, a new question. ;)

First of all: Should the data type "indicator" be interpreted as the
good old diode, glowing up to indicate s.o. s.th. special, or perhaps as
a kind of error level, like the DEFCONs with multiple meanings for each
level?

I for myself interpret it as a glowing diode and I'm wondering about the
SQL-type mapped to indicator: It's CHAR(1), but not BOOLEAN like (some)
databases would understand. Is there any background why CHAR(1) is used?

I know that MySQL didn't/doesn't(?) support BOOLEAN as type (for a long
time), but RDBMS like Postgres or Oracle support it and it's even
documented in the SQL-standard (Postgres docs say this.). Are there
perhaps any OFBiz-internal things which could cause serious problems
when using BOOLEAN?

Additionally I should say I'm developing on a Postgres-DB which will
changed to a Oracle-DB when the software will be productively used.

TIA

Best regards,
     Fabian.
Reply | Threaded
Open this post in threaded view
|

Re: Data type "indicator" - What about boolean?

Andrew Sykes
Fabian,

"indicator" is used as a boolean, and you are correct, not all DBs
support Boolean, but they all support char, hence the use of the Y/N
format.

- Andrew

On Fri, 2006-07-07 at 10:03 +0200, Fabian Gorsler wrote:

> Hi,
>
> a new day, a new question. ;)
>
> First of all: Should the data type "indicator" be interpreted as the
> good old diode, glowing up to indicate s.o. s.th. special, or perhaps as
> a kind of error level, like the DEFCONs with multiple meanings for each
> level?
>
> I for myself interpret it as a glowing diode and I'm wondering about the
> SQL-type mapped to indicator: It's CHAR(1), but not BOOLEAN like (some)
> databases would understand. Is there any background why CHAR(1) is used?
>
> I know that MySQL didn't/doesn't(?) support BOOLEAN as type (for a long
> time), but RDBMS like Postgres or Oracle support it and it's even
> documented in the SQL-standard (Postgres docs say this.). Are there
> perhaps any OFBiz-internal things which could cause serious problems
> when using BOOLEAN?
>
> Additionally I should say I'm developing on a Postgres-DB which will
> changed to a Oracle-DB when the software will be productively used.
>
> TIA
>
> Best regards,
>      Fabian.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

Reply | Threaded
Open this post in threaded view
|

Re: Data type "indicator" - What about boolean?

Fabian Gorsler
In reply to this post by Fabian Gorsler
Oh, excuse me, I've mixed up data types in Oracle. In Oracle the RDBMS
itself has noch BOOLEAN, just PL/SQL supports it.

But anyway: Why is there no explicit data type fo just logical
data with an abstraction to something like "true" and "false"? Perhaps
NUMBER(1) could be used even on different RDBMS which don't support
BOOLEAN.
Reply | Threaded
Open this post in threaded view
|

Re: Data type "indicator" - What about boolean?

Andrew Sykes
Fabian,

This would mean "parsing" every indicator field.

Not good for performance!

On Fri, 2006-07-07 at 10:38 +0200, Fabian Gorsler wrote:
> Oh, excuse me, I've mixed up data types in Oracle. In Oracle the RDBMS
> itself has noch BOOLEAN, just PL/SQL supports it.
>
> But anyway: Why is there no explicit data type fo just logical
> data with an abstraction to something like "true" and "false"? Perhaps
> NUMBER(1) could be used even on different RDBMS which don't support
> BOOLEAN.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

Reply | Threaded
Open this post in threaded view
|

Re: Data type "indicator" - What about boolean?

Fabian Gorsler
Yes, that's true. The number of operations on those fields would grow on
several layers of OFBiz (At the moment I'm not sure whether I've understood
the complete architecture.). Up to now I've just thought about a strict rule
for storing data with logical values, not about performance.

Thanks for your explanations. :)

Best regards,
     Fabian.