What is he talking about? Microsoft Access doesn’t having schema, does it?!
No, and that’s the point!
I recently came across the following discussion on UtterAccess

in which MadPiet’s comment regarding Microsoft Access lacking schemas got me thinking a little.
For larger projects, schemas can be very beneficial for organizing and grouping database objects (amongst other things). So instead of having one listing of all the objects mixed together, they are (or at least, can be) sub-divided and grouped by ‘subject’. So in a corporate database, perhaps we would have groupings like:
- HR
- Sales
- Management
- IT
- …
So what can be done in Access then to facilitate things? How can we make working in larger projects a little more bearable when we’re dealing with 100s or even 1000s of objects?
Object Naming Convention
One option could be to prefix or suffix object names with a known naming convention and then sorting objects by name.
For this to work, either the prefix/suffix need to be intuitive and self-explanatory. If you need to have documentation to cross-reference what things mean, this is less than ideal and probably going to cost time in the long run.
Prefixes are typically much better as it can be sorted on.
Using numeric prefixes is typically ill-advised as they hold no real meaning and require documentation/cross-reference table to comprehend. Things should always be simple and intuitive! Always remember and apply the KISS rule!!!
Navigation Pane Groups
Since Microsoft 2007, we have the Navigation Pain Pane (sorry for the typo). What many users don’t seem to be aware is that you can create custom groups in which you can then place any database object you wish. This can be an effective way of organizing larger projects.
What’s also nice here is you can actually assign an object to multiple groups, if required. Something that is not possible with some of the other approaches. Furthermore, you can assign any type of object within a group, so you can include the underlying tables, queries, forms all in one group so everything is accessible within the same group for development/troubleshooting.
I won’t lie though, setting up Custom Groups is a painful and tedious task involving a huge amount of scrolling back and forth. The interface for this is deplorable and needs a complete redo IMHO. It is one of these things that was created and works fine for small projects, but obviously Microsoft never tested it on larger ones or else it would not be in its current format today. That’s said, once you have things configured, it does make working easier. So it cost you initial time to save you for all of your future work.
Separate Front-Ends
Sometimes, the best solution for ones own sanity is to simply split the front-end into multiple front-ends for distinct user groups and/or purposes.
Not only does this make it easier to manage, but it can also be considered to be a security measure as users no longer have access to other components for which they don’t necessarily need access to.
Moreover, by splitting things, you reduce the overall size of each component, which in turn may be beneficial to load times, performance, …
Custom Object Management System
Yes, another option would be to roll out a custom management system, similar to the way we can secure database objects.
You could create a table with a listing of objects, assign to each object group(s) and then have a form that allows the admins to filter based on groups and then add buttons to open, edit, … and manage each as required by your project.
This obviously is a little more involved (couple hours of work), but gives your the ability to create a solution that matches your exacting needs.
Which is the Best Solution?
Well, that’s not for me to say! Each database, each situation is normally unique and only you can decide what makes the most sense for your scenario and the way you like to work.
Did I Miss Something?
Did I miss another approach? Let me know.
The post Microsoft Access Database Schemas first appeared on DEVelopers HUT.