Simply put, the more data you select, the slower it is to get the data to you. Especially if it's coming across a network connection. And a BLOB or CLOB can contain a large amount of data.
Of course if your query doesn't select those BLOB columns, then you aren't selecting the data in them, so you don't have that problem.
So the conclusion should be, if you don't need those columns in your program then don't include them in your query. But that's a standard rule, your queries should only select the columns they need. "SELECT * FROM TABLE" is likely to be lazy programming.
As for normalization, putting the BLOB and CLOB columns in a different table is a major step backwards in normalization. Normally all data which depends on a certain set of keys should be in the same table.
Many database systems have the ability to create a "view" over a table which can contain a subset of the columns. So before taking the radical step of putting the BLOB columns in a separate table, it would be worth considering fixing your code to not use lazy "SELECT *" clauses or using a view which excludes the BLOB columns. Or both.
Sounds from the discussion there as if it might be specific to MySQL.
My StackOverflow account is long dead, I haven't posted there for years.
posted 2 months ago
Paul, then let's leave MySQL.....How about SQL, Oracle..When we select only few columns other than BLOB/CLOB will there will be an impact due to huge records because we have those columns in the table...
Also, update column other than BLOB/CLOB..
Nothing? Or something? Like this tiny ad:
Two software engineers solve most of the world's problems in one K&R sized book