I'm thinking about the best way to implement unique IDs for articles. The primary concern is the unique nature of that ID, because I'm using it to access a specific article and hence the same ID can't be used more than once. In addition, I'd probably want to delete articles or just edit them.

Appart from the commen approach of implementing a counter for articles I thought about the md5 of an article.

The counter would be unique without any efford but would need to be stored somewhere. Problems arise once I'd delete an article, as then gaps within this counter would be generated. These gaps would, in an extreme scenario, be pretty big so the first article would probably have ID 5 and the next 102, 246 or so, which would look somehow strange. While this might sound not so importand, I can't see a way to fix that problem since rearrangeing the following IDs would result in links to other articles beeing lost.

The md5 of an article would avoid these gaps and the nature of the md5 prevents people from using the IDs to browse through the article instead of using the navigation. However, I'm concered that the md5 might not be unique so that there would be the potential for articles with the same md5. If that would be true, I'd had to adjust the md5 and check if the new md5 was already assigned which would probably last to long and wouldn't justify the use of the md5 over the counter anyway. The cool thing about the md5, if it would be unique, is that I don't have to worry about multiple IDs and I wouldn't need to store a counter somewhere or fix gaps for cosmetic reasons. Since the md5 has a fixed number of digits it would of course be limited in some way with an enormous number of articles, too.

To sum up, I'm wondering what you would use to generate IDs? A counter that would generate a unique ID, but would need to be stored, creates gaps after deleting articles and invites people to browse via the ID instead of the propper navigation tools? Or would you generate the md5 for every article and risk the same ID for different articles, but won't need to worry about gaps or users navigating by ID?

Please keep in mind that the IDs to an existing article can't be changed at any time to avoid losing a link to that article.

I get the idea you are over-thinking this to some degree. Just use the autonumber field type to generate unique ids

I don't get why you are concerned about "gaps" there is simply no reason to complicate things to by re-using IDs or closing gaps. All you should do where the articleID doesn't exist is to redirect to a search page so they can find the correct one.

What about visitors arriving from external links or SEs, why should they be dumped into a different article to the one they clicked or end with a default 404 page. Each one of those is a potential customer/client lost to you.

Think from a visitors perspective NOT what makes it simple for you.

I agree with chrishirst.

An ID is an ID, it serves the purpose, and shouldn't have to be changed around as much as you say to work correctly - don't fix what ain't broke right? The counter ID will work fine, using mySQLs auto_increment on the ID field will work out fine, I use it for everything on my scripts (except emails but there's a reason for that).

You'll find most sites use the simple counter style ID, check out www.deviantart.com, they use the counter for their submission id's, member id's, comment id's, pm id's etc etc. **** i think even the forum you're on now (from www.vbulletin.com) even uses the simple, easy, no frills counter ID.

Ahm it won't be MySQL but strictly PHP. Sorry for not mentioning that.

Of course IDs will be lost once removed, because there might be external links pointing to it. Because of this, there will be gaps that can't be closed. I'm also not sure if I want an easy ID because people tend to play around with them.

Anyway - is the md5 unique or not?

md5 is simply a hash string, I use it to store passwords in mysql (because there is no easy PHP function to decode it) so to be honest I have no idea what you mean.

As for the closing gap problem, why not use file names? like www.mysite.com/article/1943, that way it can be done dynamically (you'd have the same code on all the pages, but each one would call the relevant article) and if the article for that page can't be found, then simply tell them it does not exist.

I don't really understand what you're doing, excuse me for seeming rude, but sounds pretty pointless to me.

Recrehal,

There is no guarantee that MD5() hashes are unique. They are great for obscuring a password or other sensitive data, but they are not a good model for primary key generation. As much as you may be opposed to it, I would recommend using an auto-incrementer on your table. Be aware that you need not use a one-up increment -- it can be custom tailored. Increment it by 377 if you want -- start from 5000. There are things you can do to keep people from typing in "someurl?article=1" then 2, 3, 4, 5, etc. I get the feeling that is what you don't want.

Using file names was out of discussion right from the beginning as I would probably end up having the same link to multiple articles. I use names for self edited content and of course I'm using a whitelist approach so broken links will always be directed into something useful.

I really like the idea of increasing the counter by more than 1 at a time. Actually I could just generate a random increment which would be perfect for that. Preventing users from viewing content they are not supposed to view outside of the propper navigation is a concern for me, though I wouldn't know of something bad that could happen right now. Though right now there won't be any problems with people playing around with the ID there might be problems in the future and I don't want to think about that when it is to late but directly at the beginning. Problems that might occur could be articles restricted to a certain usergroup or ... well any ideas what problems could occur?