Modern systems update a whole record when only one field is being modifyed.
That is, the interface that takes all the fields is simpler to develope. For
example:

class ServiceFacade {
void updateEntity(String field1, String field2, String fiels3);
}

Are there any better practices?

"Valentin Tihomirov" <valentin (AT) abelectron (DOT) com> wrote

The main problem at the logical level of always sending every column is the
risk of lost updates in an extra-transactional concurrency situation. e.g.
If a table has two columns A and B, two users might read the same row and
then interact with the values outside a transaction. If one user makes a
change to column A and saves it and then the other user makes a change to
column B and saves it, the fact that the second person also sends the
original A value means the first person's change gets undone.

At the physical level, one must consider all kinds of factors: latency,
bandwidth, peak vs. average transaction frequencies, the number and type of
indexes etc.

Thus, for instance, if bandwidth is the primary constraining factor, sending
only the changed columns makes sense. If latency is the primary constraining
factor, having fewer larger interactions makes sense. Unfortunately, as
technology changes, the constraining factors change. At one time, memory and
storage were expensive. That's hard to believe at today's prices.

As always, design requires tradeoffs.

Ideally, we will eventually blur the distinction between our application
languages and our data management languages by raising the level of
abstraction of our programming languages to approach that of our data
management languages. Once we do that, I think we will have much greater
flexibility for shifting processing between the client and the server and
for balancing issues such as bandwidth and latency without changing our
application source-code.

Until then, try not to do anything that is obviously wrong and focus your
efforts on the problems you actually measure.

Cheers,
Bob

Valentin Tihomirov (valentin (AT) abelectron (DOT) com) wrote:
: Yes, thank you for correcting me. It is a question about style of
: application programming. I want to know opinion of DB engeneers. Whether
: should the application designers make their best or it is does not make
: sense to update a record on per field basis?

I would do what is easiest, as long as it is adequate for the task.

Notice that you often do not know whether a field has changed except by
comparing it with the existing data. After you spend time writing the
code to do that, and after the database spends time for each record to
read each field so you can compare it, it might have been simpler for you
(which also means fewer bugs) and just as efficient for the database, to
simply update the entire record if you have a reason to believe any of the
data has changed.

Also notice that updating a single column in a row in the database might
effectively mean the entire row is written anyway, since the database must
read some block of data off the disk, rebuild the entire block, and then
write that entire block back out to disk.

By all means build your update to target specific fields if it fits into
your code.