How do other databases handle this? Sounds like something to avoid to me. And in the case of this happends let it be an overflow error.
/Andreas On Mon, May 2, 2011 at 7:00 PM, Rami Ojares <[email protected]> wrote: > 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. > > -- Andreas Henningsson "Vanligt sunt förnuft är inte särkilt vanligt." -- Voltaire -- 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.
