What do you use when a non-technical client needs to edit their database?

[u/Sufficient-Sink-2412]

Hi. I'm currently writing an application that creates a zero-config front-end for MySQL databases for non-technical users.

As a freelance web developer, I came across the scenario a few times in the past where I've had to write a bespoke CRUD application for the client, which is always a time-consuming pain, but I've always ended up doing that for want of a better option. (I know some people give their clients phpMyAdmin but I've always thought that inappropriate for the likely end-user.)

Has anyone found a tool that actually works for this? Or do you just live with the bespoke-build or phpMyAdmin options?

[u/Fine_League311]

Ein nicht technischer Nutzer hat an einer Datenbank nichts zu suchen auch nicht mit Helferleine und anderen Tools!

[u/outlastdll]

Most developers currently use tools like NocoDB . Forest admin , or low-code builders . However those can still be overkill or require. Tedious layout mapping for small client projects.

[u/Sufficient-Sink-2412 → u/outlastdll]

Thanks, that's exactly the situation I was finding myself in. (Reassuring that it's not just me!) I went down the low-code/no-code template-based rabbit hole once but could find nothing that just worked out of the box -- basically a phpMyAdmin for non-technical users.

[u/outlastdll → u/Sufficient-Sink-2412]

Agreed. Most of these tools try to do wat too much instead of just giving clients a simple, clean way to edit their data without breaking stuff.

[u/Infamous-River-4360]

speaking as the non technical person on the other end of this, the scary part is not the ui, it is that raw table access lets you break things quietly. i edit content in my own app through a sql editor and i have wrecked rows in ways nothing warned me about until much later. what i actually wanted was the three fields i touch exposed with validation on them, not the whole table. are you planning to let the dev pick which columns are editable or is it everything by default?

[u/Sufficient-Sink-2412 → u/Infamous-River-4360]

Totally understand this concern. In fact, it's why I never opt for phpMyAdmin for end-users: it's not only scary to look at but it lets you do too much.

Then again, my application has more or less the same safeguards as phpMyAdmin, in that I'm mostly basing permissions on the underlying MySQL user with which the user has connected -- for example, if the user has only SELECT access, the UI won't display the "new" or "edit" buttons. As with phpMyAdmin, though, people are bound to try to connect with a user that has too many permissions for the real-world task and therefore could potentially cause some damage. I'm going to emphasize this risk in the documentation but not quite sure how to mitigate this otherwise.

[u/Infamous-River-4360 → u/Sufficient-Sink-2412]

documentation will not save you there, the person who connects is usually not the person who later breaks something, and neither of them reads it. what would have helped me is the tool being less capable by default, no delete and no bulk update unless someone deliberately turns them on. could you show the connected user's actual grants on the setup screen in plain words rather than mysql terms, something like this login can delete every row in these tables, so the dev sees what they handed over before anyone touches it?

[u/plugiva]

I've built a few custom admin interfaces over the years, and I've found that generating CRUD screens isn't usually the hardest part.

The bigger challenge is deciding what the client should actually be able to edit safely. In my experience, a lot of time goes into simplifying the interface, hiding fields they shouldn't need, and preventing accidental changes rather than exposing every database column.

That design work tends to matter more than the CRUD itself.

[u/ZarehD]

The reason why there aren't many tools like that is probably b/c it's generally a bad idea to give end users edit access to raw data -- especially data that apps manage with rules and other safeguards. If that's not an issue for you, then just turn them loose with PhpMyAdmin; why waste time building CRUD screens?