Using an auxiliary variable in your favor
Creates a list that defines the behavior that should be done in JSON itself, in each record.
Any previously sent record would have, for example, 0, saying it is a pre-existing unchanged data.
Inserted a new record? Assigns another value, for example, 1. Then the server knows to run one INSERT INTO
Deleted a record? Oops, but the guy might have deleted something that’s not even on the server yet... so basically
se(action = 0)entao
definir action deste registro 2, para executar DELETE do lado do servidor
senao
só apaga do JSON, não envia pro servidor
Same thing goes for an issue. If the person edits a record that has not yet been entered into the server you will keep the 1, but will update the data within the JSON. If the record existed previously there you define a 3, so that it is executed a UPDATE
at the bank.
This will keep you from doing 1 SELECT
For each record, the client-side effort increases almost nothing, greatly decreases the server-side problem. (You will only have to add a switch to the server part if it is already ready)
If you want to further reduce the server-side problem, you can try filtering JSON and sending everything that is not 0, so that the server is only in charge of changing the database, and not have to keep checking which records were or were not affected.
Friend I am not expert but I will leave my opinion, in the case of the update of the modified data, I believe that an UPDATE will have a better performance, I also thought of an option for you to get a way to know which ones were edited or not...so you could update just the modified ones.. I hope it gives you some light.
– Dunga Cardoso
These fields that are in the filter above the table, it is related to some other table or it is a single table ? type has 2 tables ?
– TutiJapa Wada