Tuesday, May 10, 2011

Named Queries in Relational Databases

Databases don't provide a way to create named queries with runtime arguments.  Yes we have views but most databases are accessed via programming languages where we need to construct the SQL query. We do have the Prepared statements but again they are programming language constructs and not named database level constructs.

Benefits:
1) No need to parse queries. They are callable by name.
2) Prevents SQL injection attacks because of not parsing.
3) Easy integration with programming languages.  db.execute("myQuery", arg1, arg2,...)

4) Instead of trying to optimize every SQL query, every time, database will have the list of the most important queries it needs to answer. This allows databases to save time by pre-planning the execution in the short run and in the long run, databases can optimize the layout of files or creating of indexes automatically to optimize the access pattern.
5) Easy to change db logic. As long as the query returns the same fields (may be more), you can easily change the actual query logic without changing application code.

Their is a lot in the name. 

Monday, May 02, 2011

The better side of corruption

Corruption is an enabler. It thrives on inefficiency, shortcomings of the system and provides a way to get things done for a price.  People pay for stuff that is valuable to them, hence at the very least corruption is a great validation...it validates, confirms that something is important.  The answer to the question, how do I make something better becomes self evident...fix things where their is corruption.

I wanted to move from Reliance CDMA to Airtel GSM. After 2 weeks, 6 visits of 30 minutes each and asking 10 times when should I disconnect my Reliance connection, the ultimate answer is - "Sorry your request couldn't be processed because you have not disconnected your Reliance connection".

I wish Airtel guys were corrupt. They would have known what people want, how much they want it and  the best interface to execute it.