I have been told that (at least on relational database) index types were important when it comes to compare two values, which is a pretty basic operation executed multiple times for every search.
So i got recomended to store my indexes as numerics (32bits for long) rather than string (8bits/char) considering the following
key:"1234567890" => 80bits ASCII-string
key: 1234567890 => 32bits uLong
generated:"hgYTTd4p63pdTtOR1wFG" => 160bits
As far as i m looking, firestore doesnt allow to specify key type for the document (throwing a "path have to be string" error) as well as size-type, but the default id generator is an optimized string using both upper and lower case ASCII
My question: Is index types that worthless now? How is it working? Can i safely turn any number based key into a string without slowing anything, or do i rather sur the default id generator to get the shortest key?
All document IDs in Firestore are strings, and that can't be changed. The requirements for document IDs are listed in the documentation (it's a maximum of 1500 bytes).
At the scale the Firebase operates at, using an integer wouldn't even likely actually provide much of a real performance boost. When there are billions of documents in a collection, Firstore has bigger problems to deal with than optimizing a few bytes in a document ID. It's more important actually to ensure that it has a working space of IDs that can be virtually guaranteed to store a randomly generated ID without colliding with other documents that might exist.