Re: Large set-based UPDATE

On Thu, 13 Feb 2003 19:55:08 +0000, Anurag Varma wrote:

> True ...
> But don't you think the real solution would be to break up the tables into columns which are updated by web client and to table
> where columns
> are not updated by the web client.
>
> Kinda like:
> Table A : columns (key, c1, c2, c3, c4, c5, c6)
>
> If web client only updates columns c1, c2 and c3 ... then it would be better of to
> have Table A : columns (key, c1, c2, c3)
> and Table B : columns (key, c4, c5, c6)
>
> Anurag

Absolutely. But the OP is looking for a 'short-term solution for dealing with locks', and a fundamental re-design of his normalization scheme probably isn't the quick fix he's looking for. Neither is tuning his SQL, come to that.... but since he's already proposing to alter code, it would seem that a bit of code tweaking might be an acceptable proposition.

But yes, yours is certainly a more 'thorough' approach.

To be honest, there isn't enough information to go on here to come with anything terribly meaningful. 'Early hours', the structure of the table, the spurious commits magically not inducing logical corruption (how come??!) and so on.

Regards
HJR Received on Thu Feb 13 2003 - 20:45:14 CST