Comments on: Dangers of Adding fields to Database Tables

By: Jice

Jice — Thu, 26 Feb 2009 17:43:18 +0000

In this case, of course... For some huge databases, you can't lose time.

But anyway the code should map the rows some way to avoid handling 4 fields or the 3rd field (as mentionned in the quoted part of my previous post)...
It's better to have
row["field"]
than
row[3]

Good habit is to have some MVC model and have database access objects where datas are retrieved and mapped in datastructures used anywhere else.

By: Jice

Jice — Thu, 26 Feb 2009 12:43:18 +0000

By: Ashish

Ashish — Wed, 25 Feb 2009 15:39:07 +0000

Ture, when it comes to give priority then we should give priority to maintenance over performance but there are some critical cases where we can't neglect performance too.

Suppose a large site like “Digg” where you have huge database and millions of people online doing database operations, performance becomes the key. Ideally, we should avoid the practice of using “Select *” in our queries.

By: Jice

Jice — Wed, 25 Feb 2009 14:42:32 +0000

[QUOTE]
If the front-end application is coded in such a way so that it tries to handle only these four fields...
[/QUOTE]
This seems to me a very bad coding way. Datas should be stored in structures where the fields names are specified.
And in this case, if you add a new field in the select clause, * or not, the problem will still be there.

I agree on the performance problems but a "select *" and good programming habits make database evolutions very easy to maintain : only the programs where the new field is needed should be modified.
Here comes again the big question : should I give priority to maintenance or to performance.
For me, maintenance should come first except if performance appears to be a problem...