Basically we will not perform positioned updates on the hole table data but for a data portion that it would not exceed 30 rows. That's why I said it depends on what table we're going through.
But we take care about queries performances. On 12/26/2015 09:21 AM, Vladimir Sitnikov wrote:
we cannot achieve positioned updates using the JDBC implementation
This is "functional requirement"
All of these parameters depends on what table we're going through
Those a "non-functional requirements" (see [1]). You'd better collect NFRs *before* you finalize design and write the code.
Our main problem is
Suppose you somehow achieved "positional updates". What if it turns out to be super-slow? Believe me, there are good reasons for "positional updates" to be super slow. You would have to rewrite the whole thing from scratch to make it fast.
This is why I do not want to help you to shoot into your own foot.
