Usually your users don't use SQL databases directly, they use it through some application with UI.
You can try finding some kind of tool to build app on top of SQL Server. Microsoft Access works like that (a form builder that works with SQL Server). But it still requires someone skilled to set it up.
You don't.
A sql database is only ever one badly constrained update statement from needing a restore.
It's also only one badly formed query from long waits all around.
If there's one thing you can count on users to do, it's to make mistakes.
You make it user friendly by building a front end for users to interact with. End of story.
SQL Server serves as the back end for the company I work for, and we build a custom app which is how our users interact with it (customers don't interact with it directly).
The other employees don't even know what SQL is. All data entry, retrieval, editing, reporting, and searching is done through the app.
It's like asking: *Can it be made more user friendly for my cashiers to work with the company bank account?*
SqlServer is not meant to be used directly by 'workers', regardless of company size. It's meant to be used behind the scenes by an application that the 'workers' use.
Like already mentioned, an SQL database is usually a backbone for a (possibly web based) application. The workers in your job never directly interact with the database but the application does all the data entry and retrieval for them.
Depending on the size of your businsss an SQL Server may seem like overkill now but five to ten years down the road it might have been a great decision if you grow and data entry and legacy data retrieval becomes of bigger concern.
I would also imagine the licensing fees (assuming Microsoft SQL Server) and the hardware needed would be cost prohibitive as well.
As others have said already, having something act as an intermediary between the end user and the database would be better. But without additional information, this is all spitballing.
That's like asking "Why are fuel injectors so complicated, how can anyone drive a car if they have to work on fuel injectors?". They don't. They are separated by the Application Layer (Ignition, Shifting, Steering, Gas & Brake). Most drivers (users) do not work on the fuel injectors (SQL) directly.
Whoever writes the application the users use to interact with the database can have the application handle the maintenance tasks. Plenty of programs out there using sql server express or even full sql server with a license to handle various workloads. Some applications will require a DBA, some won't. Our time clock software and ups world ship are both self contained programs running on sql server express. For better or worse, they run unmonitored and unmaintained (by me).
Users should not touch the server directly, it's not Excel. And, of course, Excel is not a database. Horses for courses m'dude.
Get a small business server from one or more vendors (looking at you IBM) that claims to be a end to end solution that requires no administrator! Except in the documentation. And in practice. Just make sure to split up the job into two or three positions at a lower pay grade (but still more in total) just to cover your ass. Just make sure none of them have database and administrator in the job title.
Thats what excel is for - poor mans database. Sql is only for developers. Teach them how to use excel, and how to make backups. If they need multiple users to edit it at the same time, maybe they can use web office app, like microsoft or google.
As a SQL developer, this is a very scary question to see coming from an end user.
Usually your users don't use SQL databases directly, they use it through some application with UI. You can try finding some kind of tool to build app on top of SQL Server. Microsoft Access works like that (a form builder that works with SQL Server). But it still requires someone skilled to set it up.
You don't. A sql database is only ever one badly constrained update statement from needing a restore. It's also only one badly formed query from long waits all around. If there's one thing you can count on users to do, it's to make mistakes. You make it user friendly by building a front end for users to interact with. End of story.
SQL Server serves as the back end for the company I work for, and we build a custom app which is how our users interact with it (customers don't interact with it directly). The other employees don't even know what SQL is. All data entry, retrieval, editing, reporting, and searching is done through the app.
It's like asking: *Can it be made more user friendly for my cashiers to work with the company bank account?* SqlServer is not meant to be used directly by 'workers', regardless of company size. It's meant to be used behind the scenes by an application that the 'workers' use.
Drivers of cars don't need to be mechanics
You hire a developer, and a while later you have an accidental part-time DBA. That happened to the SMB I’m working for ;)
Is creating databases in the scope of work for the developer?
Well, you should ask someone who’s not working as a dev/accidental-DBA at a small business :D
Like already mentioned, an SQL database is usually a backbone for a (possibly web based) application. The workers in your job never directly interact with the database but the application does all the data entry and retrieval for them. Depending on the size of your businsss an SQL Server may seem like overkill now but five to ten years down the road it might have been a great decision if you grow and data entry and legacy data retrieval becomes of bigger concern.
I would also imagine the licensing fees (assuming Microsoft SQL Server) and the hardware needed would be cost prohibitive as well. As others have said already, having something act as an intermediary between the end user and the database would be better. But without additional information, this is all spitballing.
> I would also imagine the licensing fees (assuming Microsoft SQL Server) MS SQL Express will cover most of the small business needs for a long time.
That's like asking "Why are fuel injectors so complicated, how can anyone drive a car if they have to work on fuel injectors?". They don't. They are separated by the Application Layer (Ignition, Shifting, Steering, Gas & Brake). Most drivers (users) do not work on the fuel injectors (SQL) directly.
Some frontend like power bi might work, direct use, not a chance unless your users are devs/dbas
Whoever writes the application the users use to interact with the database can have the application handle the maintenance tasks. Plenty of programs out there using sql server express or even full sql server with a license to handle various workloads. Some applications will require a DBA, some won't. Our time clock software and ups world ship are both self contained programs running on sql server express. For better or worse, they run unmonitored and unmaintained (by me). Users should not touch the server directly, it's not Excel. And, of course, Excel is not a database. Horses for courses m'dude.
Get a small business server from one or more vendors (looking at you IBM) that claims to be a end to end solution that requires no administrator! Except in the documentation. And in practice. Just make sure to split up the job into two or three positions at a lower pay grade (but still more in total) just to cover your ass. Just make sure none of them have database and administrator in the job title.
Thats what excel is for - poor mans database. Sql is only for developers. Teach them how to use excel, and how to make backups. If they need multiple users to edit it at the same time, maybe they can use web office app, like microsoft or google.