Since foreign keys are not supported by partitioned mySQL databases for the moment, I would like to hear some pro's and con's for a read-heavy application that will handle around 1-400 000 rows per table. Unfortunately, I dont have enough experience yet in this area to make the conclusion by myself...
Thanks a lot!
References:
Well, partition is not a good solution for complicate data model. If you only have 2 to 3 tables depending on each other, you may be able to do it but it is not pretty. Each table must have an column that determine the partition. Then, each table must have a trigger to create the new table, set the foreign key and unique constraint.
For example, audittransaction<- auditentry
Each audittransactionhas 0 to n auditentry. table auditentry contains the foreign key of transaction. Both table have to have column creationDate since it is used for partition both tables.
------ create a trigger to insert audittransaction within the trigger
----- then, create a trigger for autientry
Well, if you need partitioning for a table as small as 400.000 rows get another database than MySQL. Seriously. By modern standards any table below 1.000.000 rows is normally neglegible in size (not even small), unless you also dont have any index etc. And modern standards are about 10 years old in this regard.