4 ms·

I don’t agree it’s slower in a practical sense. If your service is backed by a relational database like PostgreSQL then you’d have an index on the column you’re

I don’t agree it’s slower in a practical sense. If your service is backed by a relational database like PostgreSQL then you’d have an index on the column you’re looking up. So a request involves network round-trip latency, parsing the request and preparing the response, and searching for the object in the database using the index, most likely a tree with a depth of 3 or 4 levels. I don’t think the number of characters in the key, or the data type, will play a big role here. Happy to see evidence to the contrary though if I’m wrong! The algorithm flexibility might not be a big problem either. The old slugs are stored in the database. Update the algorithm, new slugs adhere to the new algorithm, old ones unchanged, everything still works.

lxn 7y ago
1) Indexing text vs indexing integer it's very different when it comes to memory/space required by the database. 2) There is already an index on ids assuming they are used as primary keys, why adding another index (on text)? 3) To support changing slugs (titles) you will have to keep all the old slugs as well (to redirect them to their new versions). With ids you don't have to do this - ids have no reason to change. In the end you might not feel the difference in execution time, but hardware requirements for servers... I agree that they are annoying, but when the only reason against them is to improve URLs aesthetics (assuming they don't pose a security/information disclosure risk) - the trade of performance, hardware requirements and extra code needed is not worth it IMHO.
- thecatspaw 7y ago
  > 3) To support changing slugs (titles) you will have to keep all the old slugs as well (to redirect them to their new versions). With ids you don't have to do this - ids have no reason to change. Which basically means a join in the database. While not terribly expensive, its a lot more involved than a simple column value check.

lxn 7y ago

1) Indexing text vs indexing integer it's very different when it comes to memory/space required by the database. 2) There is already an index on ids assuming they are used as primary keys, why adding another index (on text)? 3) To support changing slugs (titles) you will have to keep all the old slugs as well (to redirect them to their new versions). With ids you don't have to do this - ids have no reason to change. In the end you might not feel the difference in execution time, but hardware requirements for servers... I agree that they are annoying, but when the only reason against them is to improve URLs aesthetics (assuming they don't pose a security/information disclosure risk) - the trade of performance, hardware requirements and extra code needed is not worth it IMHO.

thecatspaw 7y ago
> 3) To support changing slugs (titles) you will have to keep all the old slugs as well (to redirect them to their new versions). With ids you don't have to do this - ids have no reason to change. Which basically means a join in the database. While not terribly expensive, its a lot more involved than a simple column value check.