views:

52

answers:

2

I am working on a website and I want to make pretty urls. The urls are for certain extensions I am going to make. For example I want to have a url like this:

http://www.mydomain.com/extensions/tester
http://www.mydomain.com/extensions/worker
http://www.mydomain.com/extensions/this-is-a-really-long-ext-name

So the tester, worker, etc are all records in a database.

Now my main question is what the best way is to create the database and the queries for this. My first thought is just having the name part of the url as the primary index.

NOTE: all extensions will have a unique name.

The query in sql would then just be 'SELECT * FROM ? WHERE name = last-part-of-uri'

What are the downsides of doing this, I assume the indexes will get really long. Or is it better to use a primary index for the field, and then just a normal index for the name.

The primary index will serve no real purpose tho, maybe only in the backend.

+2  A: 

The main downside is that you will need to update your primary key when you want to rename a part of the url. You will have a lot of fun tracking the dependencies.

newtover
+3  A: 

The major advantage of numeric index - it's abstractness.
So, you can always rename meaningful part but keep unique index.
That's why, I guess, SO uses a numeric primary index for the questions:
http://stackoverflow.com/questions/2914909/what-are-the-downsides-of-a-text-based-primary-index

Col. Shrapnel
+1 Ah nice, this way you use the index internal for lookups, and to make it humanly readable you have the last part. I think I will use this method.
Saif Bechan