I found the answer: (In my case, my DB table has 520 columns in a single table which will capture the answers really many questions from a single person.)
“The pros and cons depend on how the schema is design and if it made sense to denormalize the table into the 170 column entity you posses. If denormalizing the table prove to be a benifitial thing for the majority of the query to this schema then it was a wise choice. If the net benifit to the denormalization is moot then a redesign it needed. if you sub-divide the large table into smaller table and replace the large table with a view does it impact performance? That question needs to be answered before you decide to break the large table up. There is a plus and minus to normalize database schema. When the cost is too great in term of query performance then some denormalization is needed. There is also a point where denormalizing something into infinitum defeats having a database and you are left with a giant spreadsheet. The best solution is a health medium of the 2, where you have both normalization and denormalization in a schema.”
(From: http://stackoverflow.com/questions/892960/too-many-columns-in-a-single-database-table)
Seems… the cost & time to break a single too-many-columns table into smaller VS. the loss of flexibility when adding new columns.
Actually… nobody cares except me… but I will break it into smaller ones anyway since that just looks smarter. 
