Subject | Re: [ib-support] Re: Boolean Fields |
---|---|
Author | Paul Schmidt |
Post date | 2001-12-31T13:20:19Z |
On 29 Dec 2001, at 14:31, Martijn Tonies wrote:
take 3 days at 45Kbps. Your right, the engine could probably
afford to grow a bit, however lets not go the other way, and make it
bigger just for the sake of making it bigger. I ran it on a server
(okay single user) on a 486 with 16MB of RAM, running Linux, until
the mainboard shorted out. So I will be moving it to another
machine, because a want a Linux box available for client support.
Fortunately I backed up the test database the day before. It
seems to be tradition for something to head south over the
holidays....
We have an advantage in a small, engine, it becomes more
useable, for example if I want to run a standalone application on a
Wintel machine, I can simply add ibserver to the startup menu, and
not worry about it taking over the PC, because it is small. It also
unlikely that the user will even know it's there.....
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com
> Hi,You want big, I calculated at one time, to download Oracle would
>
> >> >A true boolean would allow three values, TRUE, FALSE and NULL, so
> >> >a boolean would really be a two bit value, one bit representing
> >> >the NULL flag, and the second bit representing the true/false
> >> >value.
> >> >
> >>
> >> NULL is not a value :)
> >It is and it isn't, NULL represents an unknown value, which means we
> >need it, however there is another way to represent a NULL value, for
> >other field types, so maybe we don't need a flag on the datatype, so
> >we can get 8 booleans per byte.
>
> Right.
>
> >> >Do we really need it, probably not, here is a semi-related
> >> >question
> >>
> >> There's a difference between _really_ needing something (as in: at
> >> this very moment) and needing it. Perhaps you and I don't need it,
> >> but other engines are supporting a wide range of data- types. Take,
> >> for example, a native GUID, Boolean, Bit etc in account and it all
> >> stacks up. Every new datatype is a new feature.
> >
> >And comes with a fresh new set of problems, such as bugs, and
> >the fact that it makes the engine that much larger.
>
> Every new feature or bugfix has the risc of creating new bugs. That's
> probably what makes programming so hard ;)
>
> As for the size, currently, InterBase/Firebird isn't just 'small',
> it's extremely small and I wouldn't give a sh*t if it would grow to
> 10Mb even for embedded applications. Is size (not for downloads or
> network traffic) still a problem these days?
>
take 3 days at 45Kbps. Your right, the engine could probably
afford to grow a bit, however lets not go the other way, and make it
bigger just for the sake of making it bigger. I ran it on a server
(okay single user) on a 486 with 16MB of RAM, running Linux, until
the mainboard shorted out. So I will be moving it to another
machine, because a want a Linux box available for client support.
Fortunately I backed up the test database the day before. It
seems to be tradition for something to head south over the
holidays....
We have an advantage in a small, engine, it becomes more
useable, for example if I want to run a standalone application on a
Wintel machine, I can simply add ibserver to the startup menu, and
not worry about it taking over the PC, because it is small. It also
unlikely that the user will even know it's there.....
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com