views:

136

answers:

1

Hi!

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:

http://stackoverflow.com/questions/1537219/how-to-handle-foreign-key-while-partitioning

http://stackoverflow.com/questions/2496140/mysql-partitioning-with-foreign-keys

+3  A: 

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.

TomTom
Well, No. I couldn't find any recommendations whether to partition or not. I assumed that it would make a noticeable difference for small tables as well.
Industrial
Nope. Partitioning is basically when you run into problems with having one table. In theory for example because you keep sales per year - deleting all sales for a year is really hard work, but with partitions you can just drop the table for the one year. Small things make zero sense like that.
TomTom
Thanks a lot TomTom. Appreciate your answer. The deleting part of working with partitions is obvious, but from what I have heard previously, a partitioned table always worked better than a non-partitioned, even with smaller data sets. I have no Idea of the comparision in performance increase with foreign keys over partions however. Seems like a subject with little information about. Maybe I will have to go down the hard way to find out with benchmarking and sample data...
Industrial