I will take this into account, bean. But I can't update all the fields. I have a password field in one of the tables, and can't update this field unless I know the actual password for this user (it's a user record). The administrator is not obligated to know the password to update the user.
Other fields have simmilar problems: I don't want to update those fields unless they changed (blank fields on requests aren't considered "changed").
I'm thinking about iterate over all the fields and set an update query only for those that aren't blank. Is this an acceptable, readable, affordable strategy?
Thank you very much
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
monsieur_champs
| [reply] |
That sounds like a good strategy, monsieur_champs. I just wanted to warn you away from trying to optimize a few hundredths of a second off an update - if you were going to query the database to compare the columns so you could only update the ones that changed, that would almost certainly take more time than updating all of them. If you have valid reasons for not updating some columns, however, that's something else entirely. You could always "cache" the original values in the form and compare the cached values to the new ones - but it is unlikely to be worth the trouble.
MrChromeDome raises a good point about updating indexes and keys (with constraints) - although I would argue it probably wouldn't matter for a single update on a single table. However, in a good database design the index will generally not change when you update a record (changing the index would change its essential identity, which would be logically equivalent to deleting the record and inserting another). Also, if the column is not really changing (you are setting it to the original value), the database should be smart enough to recognize that. Another thing to take into account (when updating many rows on databases that support it) is the possibility that there is an update trigger on the table, which may do different things depending on the column updated. If you are updating millions of records, triggers, indexes, and constraints can make a big difference.
| [reply] |
Actually, if some of those columns are part of a primary/foreign key or an index, updating those columns can make a huge difference. Whatever DBMS you're using will have to either partially or completely reconstruct those index structures to account for the update.
I strongly recommend updating only those fields that you need. Aside from being a potential timesaver, it's just cleaner IMHO.
Cheers!
MrCromeDome | [reply] |
