Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Record edition management strategy needed

by bean (Monk)
on Sep 08, 2003 at 16:18 UTC ( #289804=note: print w/replies, xml ) Need Help??

in reply to Record edition management strategy needed

Updating all the fields all the time (in a single update statement) should not affect database performance in a meaningful way (unless you are using extremely wide columns), and will be easier to read and maintain than building the SQL on the fly.
As Abigail II noted, stored procedures can speed things up, but you are unlikely to save a worthwhile amount of time on a simple update statement on a single table. However, if you are querying the database to validate the data you're about to update, you would probably get a speed boost by putting the validation and update into a stored procedure, if only because you would reduce the communication between the database and Perl (another method of speeding up Perl/SQL that Abigail II mentioned).
  • Comment on Re: Record edition management strategy needed

Replies are listed 'Best First'.
Re: Re: Record edition management strategy needed
by monsieur_champs (Curate) on Sep 08, 2003 at 17:35 UTC

    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

      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.

Re: Re: Record edition management strategy needed
by MrCromeDome (Deacon) on Sep 08, 2003 at 20:27 UTC
    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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://289804]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (3)
As of 2021-04-11 08:07 GMT
Find Nodes?
    Voting Booth?

    No recent polls found