"Upgradeability/Scalability" of GUI , "non-script Database?

[WWGD]

Hi All,
I have been asking around on the "upgradeability" or scalability of GUI -based databases, e.g. Access
(using QBE) vs scripted ones, e.g., back-end SQL -based databases (no C# or PHP -based interface). I keep hearing scripted ones are preferrable in the sense of being easier to mantain, administer (e.g., restricting and allowing different levels of access - haha) than GUI -based databases. Is this mostly correct? Would appreciate your input.
Thanks.

 

[jedishrfu]

In my experience, database maintenance may require multiple records and so a script is much better.

As an example, AT&T comes to town and says that area code 999 is being split into 999 and 888 based on what towns you live in. A single SQL update could walk thru your customer table looking for all records from a list of towns and adjust the area code. Imagine doing that one by one via a GUI.

Sometimes admins will dump the database to file, perform the adjustments and reload although that could be somewhat riskier.

 

[WWGD]

In my experience, database maintenance may require multiple records and so a script is much better.

As an example, AT&T comes to town and says that area code 999 is being split into 999 and 888 based on what towns you live in. A single SQL update could walk thru your customer table looking for all records from a list of towns and adjust the area code. Imagine doing that one by one via a GUI.

Sometimes admins will dump the database to file, perform the adjustments and reload although that could be somewhat riskier.

Thanks; do you know of tacking a back end to an Access QBE front end ? i.e., how to have a scripted
database whose front end is an Access QBE database?

EDIT: Or the other way around, i.e., tacking a front end to an MSSQL , other than by using other than e.g., using PHP or C# ?

 

[nolxiii]

Completely different use cases. Need a super quick input form to keep track of some personal stuff? Can't beat Access. Need a back-end for a website or large inventory system with multiple users at different locations? Gonna need a real database. That being said, I've seen large applications built in Access and VBA doing way more than they reasonably should in any sane universe, so knock yourself out. Wrong tool for the job but building for forms in it is so drop dead simple compared to building a stand alone C# application that it just kind of happens I guess.

But yes you can connect to pretty much any database from Access by opening an ODBC connection to use Access as a front-end. And Access is also perfectly scriptable if you so desire. The Maximum size of an Access database was a gigabyte or two, unless that has changed in recent versions.

 

[jedishrfu]

You could consider something like Grails. Its a web-based framework with support for a backend database. You define the table schema in Groovy script and the Grails software will dynamically construct the associated web pages for listing, creating, updating and deleting data from the tables you defined. Later as you continue to develop your application you can customize the web page code to look more like what you want.

https://en.wikipedia.org/wiki/Grails_(framework)

and from Grails.org:

https://grails.org/wiki/Quick%20Start

 

[newjerseyrunner]

The biggest draw to normal databases like MySQL or MariaDB is the standard. If you have a question about how to do something, someone's asked that question before on the internet. If you belong to a forum like this one, you'll have a handful of members like me who know these languages inside and out.

If you want a GUI, there are plenty of options for this using script-based databases: phpmyadmin, MySQLWorkbench are two that I'm very familiar with.

MySQL also has the great advantage of running on non-windows, which will be useful if you want it to run on a headless server in the future. Also in terms of scalability, MySQL (indexed correctly with the right engine) is way faster. If speed is a concern, Oracle is ever faster with large datasets, but isn't free.