The surprisingly difficult problem of user-defined order in SQL

Re:The surprisingly difficult problem of user-defined order ... by jameshart on Saturday January 16, 2021 @12:05AM (#25800203)

What makes you say it's less efficient? It's exactly analogous to storing increasing decimal values between 0 and 1, just using base 26 digits (encoded A-Z) rather than base 10 or base 2.

Start with .M (encoded as "M"); add in .F, .T to insert before or after. Once you find yourself trying to insert between .M and .N, do it by adding .MM.

But in a database char types can be arbitrarily long, and database indexes are well suited to indexing them. That gives them a lot of advantages for this kind of usecase.

[ Parent | on HN ]

Re:The surprisingly difficult problem of user-defined order ... by CGamesPlay on Saturday January 16, 2021 @01:25AM (#25800522)

Since your alphabet is composed of 8-bit words, you'd get more mileage out of each byte by using 256 symbols in your alphabet, one for each binary value. And by using binary as your alphabet makes things conceptually simpler (even if the values are stored as 8-bit words).

[ Parent | on HN ]