The most complex project was a tracking system for software security maintenance for the U.S. Navy. We had 30+ users (variable over time), 80+ projects with people assigned to manage multiple projects' server, over 1500 servers (variable as we grew and as servers were replaced), half a dozen different operating systems (if you count LINUX, AIX, OpenBSD UNIX, and the different flavors of Windows Server as different), and about 30-40 new designated patches per month. Patches could be in multiple states (newly announced, pending assignment to an admin, pending system downtime, pending permission of manager, pending arrival of actual patch for particular vendor's system, patch failed to run, temporary waiver, completed, determined non-applicable, ... a total of about 20 statuses overall.) In the end, patches were either applied or not, but the various reasons WHY they were not applied were important to the security staff.
Any person on the project could perform the patch and update the status of that server with respect to a given set of patches. Any OTHER person on the project could query the state of their project to see what still needed to be patched. And we could make a summary report that we could send to the project manager (who was a business type, not a system admin) regarding patch activity.
The DB was able to import info on new servers from spreadsheets and was able to produce spreadsheets to summarize project/server status. We also had a help document in MS Word that, if you clicked the HELP button, would be opened read-only to a specific bookmark related to that form or that function - and you could select bookmarks by topic. We also sent e-mail to project managers when needed, and if necessary, we could encrypt the messages over Outlook.
At any given time, we might have a total of over 500,000 pending or completed actions on record. We archived the oldest closed notices every month but "oldest" was relative to the last closure. We kept records for six months after the last closure for a particular notice and archived those records to a different file for long-term retention.
There were five base tables that had a "W" relationship. I can't draw it here, but I can summarize.
Notices - were applied to individual servers via a junction table.
Users - were assigned to projects via a junction table but they had to have the ADMIN role associated in the user table. Three teams of admins were assigned to Windows; three teams were assigned to UNIX; a few people were assigned to VMWare systems.
Servers - were associated to projects via a junction; were associated with notices via a junction. The latter junction (server/notice) was the big kahuna that grew to well over 500K records.
Everything was normalized to a fare-thee-well and we had some five-way joins in that mix because of the complexity of the relationship.
Since it involves U.S. Navy computer security, two factors apply. First, it is still in use to a lesser degree and is covered by certain regulations regarding publiation, and second, I don't own the code. Therefore, I can describe it in general but cannot publish it. Third, being cognizant of that fact, I didn't take copies home with me.