Wouldn’t it be better to split this up and let different features/functions get their own numbering (perhaps their own databases even).
No.
It would be a terrible idea. How would data be normalized to accommodate the constant changes? Not to mention opening and closing a database call for everything single request, managing all the connection strings, etc, etc, etc.
Surely multiple small dedicated databases would be better than one huge monster?
No. The indexes take care of this.
Note that some plugins create their own tables in the database. I think you’re confusing DATABASE with TABLES within a database. There are times when separate tables might be better than overloading (in the functional sense) tables to support disparate data.
If you find MySQL/Maria straining, it may be that you need to look into the tuning of your database engine, though your host may not allow you access to that level of control.
Note that the post ID field is a 32bit unsigned integer so, if I recall correctly, it can handle 19 billion values.
Post ID is an unsigned bigint, meaning it is a 64-bit value. That’s 18,446,744,073,709,551,616 as the maximum value. So, 18 billion-billion.
However, First and foremost, WordPress is a CMS which started out as a blog. So yes, everything kinda falls into the “stuff is a post” category. However, where WordPress is now hasn’t really changed much from those beginnings.
It’s a publishing tool, not a store front. It doesn’t come with a shopping cart. Sure, you can use plugins and various things to add those types of things, but how they store data is entirely up to them. Should they put everything in the posts table? Who can say?
By and large, WordPress is about making webpages out of content from the database, mixed with the theme, and having enough versatility to let plugins hook into there and do whatever it is they do. From that viewpoint, yes, everything *WordPress* does is a post. It’s all about getting content fast and displaying it fast. So, if you want to build a storefront and store data in fully relational databases, then go ahead and do that. WordPress will be there to display the results from your plugin just fine. You can store your data how you prefer.
Whether or not you call it a POST ID or any other kind of ID, the fact will remain that a db needs primary keys, foreign keys, etc, etc. (and I’m not asking for a a NoSQL lesson here btw, lol)
I’m not sure why you would care the way the db structures the data, or why you would care how the WP functions and files access that data. All things considered, it works pretty well and is generally fast to access data and display data.
That said, use the right tool for the job, and one you are happy with.
Loads of people use a WordPress + WooCommerce plugin for their online shop which I personally never recommend. I dunno why it’s a thing. WooCommerce has a great marketing department I guess.