I’m writing a web application backed by MySQL, and in many cases, many thousands of rows could be created each day, possibly more depending on who is using it. It will be used to store various objects, such as posts and pages (CMS like but not a CMS).
The main objects table will host these objects, as well as revisions of the objects, and I want to reduce storage requirements and increase performance where possible. For example, the status field is an enum because enums are stored as integers, not text, therefore reducing storage space.
I am wondering if there are other techniques I should use as well.
Also, there is an object_type field. Types can be created by plugins and such. Should object_type be a field or be stored in another table and referenced by ID in the main object table (One-to-many relationship). Is the storage benefit of not replicating the data greater than the performance cost of having to make two lookups to get the data?
At first glance, this post looks like a serious case of premature optimization (some have said it is the root of all evil). Also, saying that your data storage is CMS-like but not a CMS seems rather… confused. Storing your content in a database does not make you CMS-like, it’s the workflow of handling your content (the way you enter it through to how it is displayed for the final presentation) that makes a CMS, not the underlying mechanisms.
That being said, it sounds like you are trying to optimize the data types in your tables, and that is just fine. For this sort of thing there is no better place to learn about MySQLs particulars than the documentation. After skimming through what’s available to you, it will be much easier to make informed decisions about how to organize your different schema.
Even so, do no constrain yourself too vigorously. Give yourself lots of room to breathe and grow, and if you find that your application has grown in a way that differentiates greatly from your original design path, you can revisit the issue then pretty easily. This type of optimization barely affects disk space even in the millions of rows per table, with dozens of tables, as long as you were even marginally close to your actual use case.
For efficiency of queries, the best I can offer is using JOINs effectively to constraint how much data you are relating per query.