Welcome to the forum. That's an impressive amount of tables. We don't see that often here. I don't want to be negative right away, but such a large amount can also indicate a not quite right design. Anyway, you've made me very curious. Can you tell us more about the database?
XPS35, I am more than happy to describe the database to you.
It is designed to be used by companies that pursue multi-million dollar contracts (>$10M US) and take months (6 to 24 months) to develop a proposal. The primary domains include: customers, competitors, personnel, projects, partners, and company. It uses principles in the project management, sales management, proposal management, TRIZ, OODA Loop, and Six Sigma bodies of knowledge, which I have studied since 1998. I have gotten ideas from different books, Harvard Business Review, MIT Sloan, and other places. There's even psychometrics based on the Myers-Briggs Type Indicator and ideas from the Four Disciplines of Execution. I spend more time reading business and technical literature than working on the database.
Unlike many Access databases, mine focuses on the end user. All of the forms/subforms have a custom graphic because Access charts don't do it for me. Many graphics replace radar diagrams and histograms using images resembling flowers, racetracks, and volcanoes. I hate pie charts so you won't see any in the application. There are a few donut charts, but they are custom. I have given charts special names, such as the Tungsten Wheel and the Holscher Fan. I have many versions of these graphics in the application.
Many of the forms (4600+) also use text-to-speech to read information aloud. Some of the reports read information aloud when they are initially opened. The reports (3200+) use the same objects that are in the forms.
The tables (4100+) range from two-field lookups to master tables with 200 fields. The lookups are used mainly for multi-value fields. Some of the forms/reports have 10 MVFs. I use them to ensure consistency in assessments.
The database uses very little code because I don't code, and this database doesn't need it because it is more information-based than most Access databases. By that, I mean that it is designed to generate multi-page reports about each record. So one of the key data types is long text (memo in old versions of Access).
The database also uses many multi-value fields to make it easier for users to conduct assessments using the same statements or questions. If there were no MVFs in Access, I probably wouldn't use it.
I haven't worked on the user manual in years. The last time that I checked, it was more than 400 pages. I suspect that it will be several thousand pages when I finish it.
The style guide is 50 pages because I use a lot of screenshots. I started working on it a week or so ago.
The database has been at the 2Gb mark for a few years. I am in the process of separating domains. I backup regularly in case the application crashes under its own weight. Compact and Repair is a lifesaver. It brings the file down in size regularly.
As you can see, I have deviated from standard DB practices in many ways. Many developers would say that my DB is not normalized. What can I can say, tables with 200 fields work for me. Others don't use MVFs. Again they work for me. Most developers do not create and use their own graphics. I am a visual thinker, so I need graphics to write and think. Most developers do not use speech. I want certain objects to talk to me and then play my favorite music as I work.
XPS35, I hope this helps.
You can see some of my forms and reports on LinkedIn in the Modern Access Designs group. I have also made presentations at Access DevCon, Access Pacific, and LunchtimeAccess.