5 ms·

Alternative why not have both? Use the meaningful url as most links, but have a randomly generated perma link that will always redirect to the same article

by consto 10y ago

PavlovsCat 10y ago
Or sequential numbers, if you don't need to hide anything from being discoverable that way. Or is there another downside to that? I use "slugs" for category type nodes like "photos" or "blog", but I don't give individual "things" a slug (never liked the idea of putting the title into the URL just for SEO). And of course, everything that has a slug always also has the numerical ID and can be reached both ways. Now that I think of it, I might add a table keeping track what nodes slugs were used for, and in case of 404 either redirect when there is only one option, or display all the nodes that once used that slug if there is more than one. Seems like that would be the next best thing to an actually never changing URL, right?
- chriswarbo 10y ago
  > Or sequential numbers, if you don't need to hide anything from being discoverable that way. Or is there another downside to that? Sequential numbers either require state, which must be kept in sync (e.g. the current-highest index, or the set of all URLs used so far which you can take the "max" of); or else their discovery process is slow (i.e. keep looking up URLs until you find the highest unavailable one). Random numbers don't need state; you can either make the space really huge, and ignore the potential for collisions; or else you can look up the generated URL to see if it's in use, and only have to perform another check in the unlikely case that it is. Whilst it may be easy to maintain the state for sequential numbers (if, say, they already exist as database IDs), the failure mode of random numbers is better. If something goes wrong with the lookup process for random numbers, e.g. it might miss a collision, we're still protected by the incredibly low chance of collisions in the first place. For sequential numbers, we're guaranteed to hit a collision in this case, i.e. if a glitch prevents the state from getting updated, the next URL will definitely collide with the previous URL.
  - PavlovsCat 10y ago
    Yeah, I was thinking of auto-increment database IDs actually :)
  - MichaelBurge 10y ago
    In Postgres, sequences are guaranteed to be monotonically increasing even in the presence of failed transactions. So retrieving an index using nextval()[2] will never collide[1]. [1] A malicious pedant could create situations where it wraps around or collides. [2] http://www.postgresql.org/docs/current/static/functions-sequence.html http://www.postgresql.org/docs/current/static/functions-sequ...
    - chriswarbo 10y ago
      > In Postgres, sequences are guaranteed to be monotonically increasing even in the presence of failed transactions. Well, I was talking about what happens in case of failure; not the chances of a failure to begin with. If, hypothetically, Postgres forgot to update a sequence number, then a collision would be guaranteed, since that's a property of sequential numbering: all updates are contending for the same "next" number, and must be managed in some way. Random numbers spread across a large range, so work even without management. Even if we ignore the possibility of bugs in Postgres, or cosmic rays flipping bits in RAM (which may have a similar probability to a random ID scheme colliding), etc. that's still only true inside the confines of Postgres. Once data starts working its way through layer after layer of shell scripts, caches, proxies, etc. there's a lot of scope for things to go awry. Plus, since we're talking about longevity, there's no guarantee that we'll still be using Postgres in 20 years' time, or maybe we need to migrate or integrate with some other system, etc. I'm reminded of the "one in a billion" chances that used to be claimed for DNA evidence in court. It is certainly true that the probability of two non-twins having identical DNA is that low, but that doesn't really mean much; even if the probability of identical DNA were zero, that doesn't tell us anything about the collison rate of the sub-set of bases which were used, or the error rate of the sampling process, or the mislabelling rate of the lab, or the corruption rate of the evidence handlers, etc. :)
- oneeyedpigeon 10y ago
  > never liked the idea of putting the title into the URL just for SEO What about for indicating the likely content of a URL, when all someone has is that URL?
  - PavlovsCat 10y ago
    Oh, that's a good point. There's really something to be said for hovering a link and getting more than just random numbers and letters. And I know this as a user, but I never thought about the stuff I make in this light.. thanks!
justusthane 10y ago
Because other people will also link to it using the "meaningful" URL, and when that URL changes the links will break, and now you've defeated the whole purpose of using URLs that don't change.
- Natanael_L 10y ago
  Let your sitemap page provide a URL history database (directly accessible from any 404 page too!) for every non-permanent URL. That way you can find old permalink mappings for your links.

Alternative why not have both? Use the meaningful url as most links, but have a randomly generated perma link that will always redirect to the same article

by consto 10y ago

Alternative why not have both? Use the meaningful url as most links, but have a randomly generated perma link that will always redirect to the same article

PavlovsCat 10y ago

Or sequential numbers, if you don't need to hide anything from being discoverable that way. Or is there another downside to that? I use "slugs" for category type nodes like "photos" or "blog", but I don't give individual "things" a slug (never liked the idea of putting the title into the URL just for SEO). And of course, everything that has a slug always also has the numerical ID and can be reached both ways. Now that I think of it, I might add a table keeping track what nodes slugs were used for, and in case of 404 either redirect when there is only one option, or display all the nodes that once used that slug if there is more than one. Seems like that would be the next best thing to an actually never changing URL, right?

chriswarbo 10y ago
> Or sequential numbers, if you don't need to hide anything from being discoverable that way. Or is there another downside to that? Sequential numbers either require state, which must be kept in sync (e.g. the current-highest index, or the set of all URLs used so far which you can take the "max" of); or else their discovery process is slow (i.e. keep looking up URLs until you find the highest unavailable one). Random numbers don't need state; you can either make the space really huge, and ignore the potential for collisions; or else you can look up the generated URL to see if it's in use, and only have to perform another check in the unlikely case that it is. Whilst it may be easy to maintain the state for sequential numbers (if, say, they already exist as database IDs), the failure mode of random numbers is better. If something goes wrong with the lookup process for random numbers, e.g. it might miss a collision, we're still protected by the incredibly low chance of collisions in the first place. For sequential numbers, we're guaranteed to hit a collision in this case, i.e. if a glitch prevents the state from getting updated, the next URL will definitely collide with the previous URL.
- PavlovsCat 10y ago
  Yeah, I was thinking of auto-increment database IDs actually :)
- MichaelBurge 10y ago
  In Postgres, sequences are guaranteed to be monotonically increasing even in the presence of failed transactions. So retrieving an index using nextval()[2] will never collide[1]. [1] A malicious pedant could create situations where it wraps around or collides. [2] http://www.postgresql.org/docs/current/static/functions-sequence.html http://www.postgresql.org/docs/current/static/functions-sequ...
  - chriswarbo 10y ago
    > In Postgres, sequences are guaranteed to be monotonically increasing even in the presence of failed transactions. Well, I was talking about what happens in case of failure; not the chances of a failure to begin with. If, hypothetically, Postgres forgot to update a sequence number, then a collision would be guaranteed, since that's a property of sequential numbering: all updates are contending for the same "next" number, and must be managed in some way. Random numbers spread across a large range, so work even without management. Even if we ignore the possibility of bugs in Postgres, or cosmic rays flipping bits in RAM (which may have a similar probability to a random ID scheme colliding), etc. that's still only true inside the confines of Postgres. Once data starts working its way through layer after layer of shell scripts, caches, proxies, etc. there's a lot of scope for things to go awry. Plus, since we're talking about longevity, there's no guarantee that we'll still be using Postgres in 20 years' time, or maybe we need to migrate or integrate with some other system, etc. I'm reminded of the "one in a billion" chances that used to be claimed for DNA evidence in court. It is certainly true that the probability of two non-twins having identical DNA is that low, but that doesn't really mean much; even if the probability of identical DNA were zero, that doesn't tell us anything about the collison rate of the sub-set of bases which were used, or the error rate of the sampling process, or the mislabelling rate of the lab, or the corruption rate of the evidence handlers, etc. :)
oneeyedpigeon 10y ago
> never liked the idea of putting the title into the URL just for SEO What about for indicating the likely content of a URL, when all someone has is that URL?
- PavlovsCat 10y ago
  Oh, that's a good point. There's really something to be said for hovering a link and getting more than just random numbers and letters. And I know this as a user, but I never thought about the stuff I make in this light.. thanks!

justusthane 10y ago

Because other people will also link to it using the "meaningful" URL, and when that URL changes the links will break, and now you've defeated the whole purpose of using URLs that don't change.

Natanael_L 10y ago
Let your sitemap page provide a URL history database (directly accessible from any 404 page too!) for every non-permanent URL. That way you can find old permalink mappings for your links.