Hi Guys, Thanks for all the help in my previous threads. I wanted to start another discussion about the general approach I am taking to making a "bit.ly/tinyurl.com" service. The service is part of a bigger set of function I am adding to a website. But one particular function I want to roll out soon is the redirection function.
I was hoping to talk about my methodology in creating this service, and before I start fine tuning it, double check to make sure I'm not doing something very bad or working with a design flaw. It is working as I want it to, along with keeping stats of hits, etc. However, I'm not sure if the way I made it work is the best. As I worked on each individual component, I was told on forums and here that my approach was just fine. But now that it's 'done' I want to make sure. All of the redirects will be kept in a table of which I will also index with Lucene. Hits, for stats, will be kept in a seperate table. I figure that even if the site is successful enough to have 10million redirect entries, between db caching and having a tuned index, this shouldn't be too much of a problem for one table of records. If not, I can easily split the two into multiple parts. Same situation with the hits table. Before I list the table structure, let me first mention some business rules. In order to create custom redirect, where you decide on the subfolder, you will need to be a member. However, anonymous users can still create a redirect like bit.ly, which creates a random subfolder string aka '7FG3R'. Also, in order to edit where the redirect goes, you will need to be a member. Otherwise, anonymous redirects will have a lifespan which can be decided by the creator. This is typically 3 years and as long as it is clicked a certain amount of times before it expires, it will renew automatically. Here is a basic outline of the table structure I am using. ------------------------------------- Redirection Service - redirects_table - hits_table Table - Redirects id (int-identity-pk) member_id (int-fk) (required for custom entries) domain (varchar-20) (required) subfolder (varchar-30 (required) redirect_url (nvarchar-255) (required) created_date (datetime) (required) cycle_date (datetime) (only required for anonymous entries) duration (int) (only required for anonymous entries) status (int) (active/inactive) *cycle date will change if redirect is renewed past its expiration date, hence two date entries Sample record 2345,45,company.com,openbd, http://openbluedragon.org, 7/30/2009 10:28:28 AM, 7/30/2009 10:28:28 AM, 36, 1 This says that member with ID of 45 created a url redirect on 7/30/2009 10:28:28 AM that is set to expire 36 months from 7/30/2009 10:28:28 AM, is active, and when users type 'company.com/openbd' they will be redirected to http://openbluedragon.org. Table - Hits hit_id (int-identity-pk) redirect_id (int-fk) (record ID of redirect being hit) hit_datetime (datetime) (datetime of hit) referrer_type (vchar-50) (referrer type - browser, etc) location (varchar-8) (Country, USA, Canada, etc) ip (varchar-15) (ip address of hit) Sample Record 94567,2345, 9/27/2009 04:28:28 AM, Mozilla bla bla, US, 65.12.78.113 ------------------------------------------------ Ok, now that the structure in which I will keep all my data is laid out, let's talk about how it's actually used. Let's say we are going to use the sample record for company.com/openbd that I mentioned above. the 'openbd' folder after company.com doesn't actually exist. I have a script that runs as the default error handler. So when a request is made for company.com/openbd and the webserver finds that this location does not exist, it defaults to the error handler (which is defined in the bluedragon.xml file). At this point, before generating an error, the script parses from the request the 'domain' and the 'subfolder', checks the redirect folder for a match, checks if it is active, and if so, does a "CFLOCATION" operation to redirect the user to the website in the table. Step 1. User requests company.com/openbd Step 2. Webserver processes request, does not find OpenBD location Step 3. Webserver defaults to error handler, finds that there is match Step 4. Webserver, using CFLOCATION, forwards users to http://openbluedragon.org And that's that. There's a lot of little things going on in the script (such as parsing the url, updating the hit count), etc. But what is above pretty much sums up how I am making this work. What are your thoughts? -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
