[pravus]

I worked at an educational institution where we ran an academic-focused Enterprise Resource Planning (ERP) system that was fairly large. Not quite 40k tables, but it had over 4k. To give you an idea of how this was organized:

    * Most simple things like a "Person" were multiple tables because you had to include audits and historical changes for each field
    * A "Person" wasn't even all that useful because it included guests or other fairly transient entities like vendor contacts so you had an explosion of more tables as you classified roles into "Student", "Faculty", "Employee", etc... (many with histories as above).
    * Addresses and other non-core demographic information were usually sharded into all sorts of categories like "primary", "parent's", "last known good", "good for mailing", etc... (more histories, etc...)
    * All coded information like label types such as "STUDENT", or "MAILING" were always handled as separate validation tables with strict FK constraints and usually included extra meta information like descriptions and usage notes within parts of the system.
    * Each functional sub-system (HR, Payroll, AR, AP, etc.) had its own dedicated schema.
    * All external jobs, processes, and external integrations were configured separately.
    * All enterprise integrations usually had a whole a dedicated schema for configuration.
    * Most parts of the interactive web UI were database driven (Oracle's Apache mod PL/SQL) with many templates and other components stored in large collections of tables.

I'll stop there, but basically just imagine a very large application that tries to be 100% database-driven. That's how you get a lot of tables.

[Spivak]

And honestly, I kinda get it. Until you run into a case where your volume is such that you physically can't run on the db then run it on the db. I run all my job processing off the DB and couldn't be happier. I have to hit "can't run along side the real data" and "can't run in its own db" before I'll need to consider something else.

It probably feels weird for devs to drive the UI off the db but it's just Wordpress by another name.

[Cthulhu_]

I've worked with / on an application like that, it had all form fields awkwardly configured in a database, plus a complicated database migration script to add, remove and update those fields.

When I rewrote the application I just hardcoded the form fields, nobody should need to do a database migration to change an otherwise mostly static form.