undefined | Better HN

0 pointsjnordwick9y ago0 comments

You can definitely get around the currency issue by scaling yourself, but things like the timestamp issues (fractional seconds since the epoch with millisecond precision) are a little more problematic. You basically have to roll your own datetime format and lose any db support.

Databases are about data after all. Why not have a rich way to describe it?

0 comments

SamReidHughes9y ago

I think so too. But I don't think, say, not having a 32-bit integer type, and 16-bit and 8-bit integers, is a big problem, if you've got doubles. Maybe it's a nice-to-have. A 64 bit type or bigint would add real value.

jnordwickOP9y ago

I think as far as number types, you NEED (in the you should be considered seriously broken even if you can hobble along without) to have:

- a 64-bit float

- a 64-bit int

everything else can be emulated in code from there and you can play all the encoding games you want to save space when you don't have to use it. This covers 99.999% of the use cases you reasonably see.

From there, I would argue, you should also have:

- a bit and byte

- 32-bit ints

- 32-bit float

- 128-bit int (once you add UUIDs you might as well make them full numerics citizens).

If I were doing a modern database, I'd have the kitchen sink as a type full numerics from 8 to 128 bit both signed and unsigned int and all supported hardware float sizes. I'd probably even have a 512-bit AVX type just to see what people would use it for.

Dylan168079y ago

Why do you NEED a 64 bit int? Why not 32 bit? You're not storing pointers in a database. (And then you can implement your 32 bit int in terms of the 53 bits of int-capacity in a double.)

2 more replies

j / k navigate · click thread line to collapse