Quote from Nickj_UK on February 27, 2025, 12:00 am

Just some general thoughts based on experience implementing large systems (medical imaging, high concurrency, high bandwidth and 'mission' critical. Last system I was involved in was growing, just in images, by 20Tb a year and that was just a specialty sub-section of the whole group). I didn't write the code or design databases but had to understand what was happening with the interfaces and system integrations to write project specs, user documentation and user training for multiple roles:

Optimising is making things run quickly and reliably, reducing code steps when and where you can.
So at a simple level if you have something that is repetitive say a code section that is used several times then it becomes a single subroutine that you call when needed rather than be re-written each time. That's supported on VisualNEO so leverage it

Databases especially as they get bigger eat RAM on a PC and CPU cycles, the bigger they get the slower they get. You have to assume a common standard of performance between systems running your app, that they aren't also running other software that is also competing for resources and that there isn't someone somewhere on an ancient pc with 2gb ram and an 800x600 monitor. It does happen!!
One database running on multiple discrete instances starts to get data integrity problems as soon as more than one starts running, they need to synchronise data and that will become a nightmare. Anything that runs database access concurrently requiring data reads and writes is better managed remotely as a single instance, to be frank really not better managed but it's essential to manage it.
Access based databases are OK for development but production really warrents a 'real' database, note that microsoft don't recommend the use of access for anything requiring concurrent access, just for early development on a single instance. More than one instance with a data rich source and you need an sql server. It isn't too much of an issue to migrate from access BUT it's easier to not to have to and start on a server based database. Run a local sql server stackon your PC, even a DB running on a raspberry Pi 4 or 5 LAMP stack will work fine. It also allows you to leverage the stack to built your real producction database later.
Don't forget that you also need to optimise the database, just having a fast server running it won't always hide a design error, smart use of indexing will speed up queries significantly, it's far easier to do this before you run into performance problems. Things like having a good base design, normalising your database, NEVER using SELECT* or non-specific queries and always only retrieve the data you need, no more and no less.

The User Interface is tightly bound to the User eXperience, a good UI with a decently performing back end leads to a good UX. A bad UI gives a bad UX but a good UI with poor performance still gives you a bad UX and usually a bad UI gives an abysmal UX which gets even worse if the backend is glitchy. It's why UI designers, database designers and coders still make good money.
You might consider signing up for a course on UX and accessible design if your experience is limited or you want a fresh perspective on it.

Could you use multiple 'files'? I assume you mean concurrent apps?
I would think that you could but would you want to is the question?
With one large app it's a pain, split into two it's potentially double the pain unless the design is very good. If there were two apps one for just for input of data and one just for queries it might work but then the user might well be jumping between apps, that tends to make for a bad UX. You'd also need a consistent UI to not confuse users BUT might confuse the users if pages they use look similar so you then need to have app A and app B being sufficently different so that makes more work.
One single app that is well designed will always be better.

Assuming you have an idea of the data structure you can start to model it. You need to process map what the users are doing before you do anything else, the task sets that are required and the steps in each task as this forms the frame that dictates where your UI is heading. Once you know exactly what is required rather than thinking that you know it maybe doesn't get easier but it lets you see where the user tasks can be split or can be cascaded between smaller input branches and the path through multiple branches to capture the only data you need for a task.

Not really that helpful I guess but the essence of this is that you need to fully understand the task(s) step by step {process mapping} and design everything to reflect those steps before you do anything else. That's all 'paper' exercises.
This 'mapping' and design will help to give you a framework that will help to identify an optimal path towards implementation (hopefully!)
It will also document the app in detail and that will roll over into the implementation, the back end code required and even user documentation.
Once you really know what you are doing you can fire up your VisualNeo and start to out things together.
Oh and use a framework to organise your own tasks, maybe an agile model, it might feel over the top but it keeps all the strands running along.