Commonly Common Misconceptions*

Well the purpose of this post is to clarify some misconceptions regarding programming and database concepts. I am sure I will be making some mistakes but I will try to stay correct to the best of my knowledge 🙂

1. HTTP Request Request Object:The Request object represents a HTTP Request before it has been sent to the server. In contrast to this is the Response Object which represents a valid HTTP response that was received from the server. The response header properties are read-only. If I go a bit deeper then we also have an XMLHttpRequest Object which is available in the window (open window in the browser) object in IE7 and later. This object actually enables you to submit your request (XML) to the web server and get data back without reloading the entire page. Prior to IE7 you need to create an ActiveX object of type Microsoft.XMLHttp This object is the foundation behind the
AJAX which is quite a buzz word these days. And one last point to wrap it up is, you can use the client side XML DOM or XSLT to render XML into representable HTML elements on the page.

2. Overloading: The concept of overloading is simple i.e. create similar methods with different signatures e.g, GenerateGridCols(int size); vs. GenerateGridCols(DataSet ds, int size); Well this is all too simple. My point is regarding overloading based on the return type! What if we have: public string MyFunc(string myParam); vs. public boolean MyFunc(string myParam); Is this still an overloading ? Well it’s but it won’t compile 😀 the problem with this is that for the compiler to decide which method to call is totally dependent upon the return type which will come in the end of the method execution. So which way to go for can only be determined by reaching the end first! Hey don’t jump into the conclusion; if you read the design guidelines around method overloading then it’s pretty clear that you should only overload methods that do SEMANTICALLY the same thing. That is you should be able to change your code from calling one to calling another without substantive changes to the rest of your code. Now I seriously doubt that this is not happening in our case. One method is returning a string while other is returning a Boolean. Probably the developer wants to validate something here, mmm then won’t you be writing as: public boolean IsMyFunc(string myParam);. I don’t see how you can change the return type and keep the method semantically the same. So let’s make this our conclusion here: Do not overload the method when you are changing the return type! 😉

3. Surrogate Keys: According to the Websterýs Unabridged Dictionary, a surrogate is an “artificial or synthetic product that is used as a substitute for a natural product.” That’s a great definition for the surrogate keys we use in databases. A surrogate key is an artificial or synthetic key that is used as a substitute for a natural key. Now here there are two concepts that are quite confusing: An intelligent key is one that uniquely identifies a business process. E.g. a user might give a unique id to each customer thus customer_number naturally serves as a primary key for the customer table. Surrogate key on the other hand is an artificial key to uniquely identify the data. Let me expand my example to fit in the surrogate keys. E.g. we can also have an order table that might have an intelligent primary key consisting of two columns i.e. customer_number that acts as a foreign key to the customer table and an order_datetime to identify different orders for one customer. Can’t we have a simpler solution for our keys here to uniquely identify the records? Yes we can have artificial keys here. You heard me right, use system-generated artificial primary key values! These are called surrogate keys because they are replacements for the intelligent keys, or blind keys because the user doesn’t see them. The primary key to order would be a surrogate customer_id column whose value would be set to 1, 2, 3,… as new rows are inserted. The customer_number column would still be included in the table, with a unique index, but it would not be part of the primary key. The primary key to the order table would now consist of a single surrogate order_id column. The customer_id column would be included as a foreign key pointer to the parent table but would not be part of the primary key. Order_datetime would also be included but it too would be an ordinary data field. The customer_number column would be dropped from the order table.

In my coming post I will be adding more into it, some commonly common misconceptions and concepts!

Happy Coding~


One thought on “Commonly Common Misconceptions*

  1. You are doing well but to make your article more readable, just express it in the form of bullets.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s