On 2.5.2011 18:39, Maaartin G wrote:
On Monday, May 2, 2011 5:20:01 PM UTC+2, Rami Ojares wrote:
> The original problem from where this discussion comes from is that type
> INTEGER
> has been split into many types (SMALLINT, INT, BIGINT...) because of
> historical implementation concerns.
Whatever the original problem may be, it's not shown in my Google
Groups. The first message I see is "... Do you really want the
database schema to change without knowing it." from 11:38 AM (5 hours
ago) by Andreas Henningsson.
I might have been imprecise.
I meant that the origin of the issue of integer overflow.
This origin is not related to google discussion forums neither H2.
> Java has made the same archaic mistake (short, int, long...).
It's neither archaic not a mistake. Java as a mostly general purpose
language needs to come a bit close to the machine level for (mainly
storage) efficiency reasons. The storage is irrelevant when working
with single values, but replacing byte[] by long[] or even
BigInteger[] would be very costly.
I might have been a bit polemic.
I understand that using 1 byte instead of say 16 bytes to represent
integer 1 is more efficient.
But it is also clear that one could just define a variable as integer.
This would only mean that all values assigned to that variable are
integers, big or small.
And then under the hood (without intervention by the programmer) the
execution environment (jvm for java programs, h2 for sql statements)
would choose the optimal storage size for that value.
Consider strings in java. We do not define how long our string will be
(like sql has forced us to do with varchar(n)).
Instead the execution environment picks for us the most efficient
storage for that piece of data.
And thus the set of strings are closed over addition (or should we say
concatenation).
> The best solution would be to have an Integer type that can (in
> principle) scale up to infinity.
> (Of course it would be wise for the database to define some limit so
> that erroneous code would not end up creating an infinite value.)
This would be not the best solution, just the easiest one to use - but
also the slowest (and most memory consuming) one.
As I explained above, the execution environment can pick the most
efficient storage under the hood for each and every value of the integer
type.
That's what it is doing currently with strings.
> Then one could set some further constraints on the INTEGER type eg.
> CHECK COL > 3 AND COL < 7 or whatever.
>
> The heart of the problem is that in mathematics the plus operator when
> applied to 2 integers ALWAYS produces an integer.
> This is called the closure property.
> The set of integers is closed over addition (multiplication).
So is the set of ints/longs in Java, using modular addition instead of
the normal one. This is the price for efficiency.
> But this is obviously not true for SMALLINT, INT or BIGINT.
You're right, and there's BigInteger doing what you want - at least in
Java, no idea about H2. Supporting BigInteger in H2 might be simple
and maybe even useful. But which other database allows it?
BigInteger in java is very cumbersome to use in normal situations where
you want to use integers.
Further it is not well optimised for small integers which are by far the
most common integers used.
- rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
