Subject | Re: reorganise id's (OT) |
---|---|
Author | Adam |
Post date | 2006-05-15T23:54:23Z |
> this may seem like a stupid question but when i declare a table fieldNot at all stupid, probably the most on topic question in this thread
> in firebird as an integer, what is it internally by default? 64 or 32
> bits? if 32 bits, how do i change that to 64 bits?
so far ;)
Integer means 32 bit signed whole number.
BigInt means 64 bit signed whole number.
Generators return a BigInt, which will obviously cause an overflow if
you assign it to an integer Field when it has a value bigger than that
which would fit.
As far as integers (32 bit) go, you have
2^32 potential values, (2^31)ish are greater than 0.
This means the largest number you can store in a 32 bit integer field
is 2147483647. As someone has already pointed out, in a high volume
database, this will be a limitation in some systems. The common
misconception is that 64 bit is twice as big as a 32 bit integer. A 33
bit integer (if it existed) would be twice as big as a 32 bit integer,
and a 34 bit integer would be twice as big (as the 33 bit integer).
A 64 bit signed integer can store numbers between
-9223372036854775808 and 9223372036854775807
If you dish out, lets choose a big number, 100,000 per second (anyone
have hardware that could cope with that load), you would have about 3
million years to come up with a new solution. I will remind you at
this point, that each field must be by definition 8 bytes (at least,
you have null flags etc to consider as well). Lets put some context.
If you simply had a table with a BigInt field and no other fields, and
assuming that there was no record overhead (which there is), and you
managed to insert a record for every possible BigInt, you would need a
database that was around 7 million Terabytes.
NTFS has a limit of 256 Terabytes, and Firebird has several limits
that you will hit well and truly before this one. So I am not worried
about running out of generated values.
Adam