Simultaneous user edits to the same row but different columns

[Kyric]

Hey all,

I'm using AppSheet with an SQL database - this may be a question more about database structure instead of AppSheet

I've realized now that AppSheet processes any row edits as a full updated row, so if I have multiple users editing different columns of that row at the same time, only edits made by the last synced user are saved

I'm mostly powering the app with one giant table where each order has its own row. The order has many stages of status updates and progresses through the app mostly in chronological phases, and generally there isn't much overlap of users editing the same row - but accounting changes for the order can happen while the order is still progressing - leading to an accounting user overwriting an operations user for the same order.

The app is using the sync after every change option, so overwriting is fairly rare and minor, unless an unsynced user is doing some batch updating via actions or Quick Edit

I imagine this problem will only get worse as I scale the app to more and more users as the operation grows.

Is the best practice here to split this large table up at the points where I think simultaneous edits could occur and use reference columns for each table to talk to each other? Split up operations and accounting, or maybe even split up each phase of the order's life cycle?

Is there a way to split this up in AppSheet?

Apologies for the long-winded explanation - pretty new to all things dev and just want to make sure I've explained this fully. Thanks in advance for replies!

[SkrOYC · Accepted solution]

---

@Kyric wrote:

Is the best practice here to split this large table up at the points where I think simultaneous edits could occur and use reference columns for each table to talk to each other?

---

Kinda, if it fits your needs, it's rare to have a "large table" that's normalized.

---

@Kyric wrote:

Split up operations and accounting

---

Most probably a very helpfull thing

---

@Kyric wrote:

maybe even split up each phase of the order's life cycle?

---

Related to the first part, using multiple tables vs one large one.

---

@Kyric wrote:

Is there a way to split this up in AppSheet?

---

It's up to you, not an AppSheet thing since AppSheet isn't a database management product.

One last thing. If you have problems with multi-user interaction, a good practice is to make another table where changes are stagged using just adds and a bot is incharge of the editing so that basically there is just "one 'user'" doing the interaction with the important table, but this wouldn't be easy to do as it's a workaround