I’ve seen similar questions on one complex join vs multiple queries, in which case the answers is always “it depends” haha, but I was wondering if I could get input on direction. Hopefully it won’t be too complicated to explain.
I am displaying a page that has to pull information from about 3-4 different tables. Let’s say we have an a person that could belong to a club, and that club has many events. I would have to pull information form the club, the person, the event information, etc.
Right now I have them in 3-4 separate tables, but my events table has a large number of columns that I’m pretty sure is not normalized, but I keep it that way so that I don’t have to do more than 3-5 joins max. Right now it seems to be fine with a small dataset, but I can’t help wondering if splitting them up into 3-4 individual queries and then caching the results of some of them would be quicker? The events table is updated fairly often, so I can see that being invalidated, but the organization and user table do not so I can see that being benefited by the latter solution. So which would y’all recommend?
Also related to this is that my events table has a large # of columns, some of them storing data that is frequently updated or large text columns to store serialized key/value template data. Would it be wise to partition that out to another table, so I have “general” data and then event data that is frequently updated? Thanks for any help.
Without testing against your particular set of data and tables and how frequently they are used, there is not a good answer.
It looks like you have a good grasp of the pros and cons of each. If you have space for caching a lot of data, or if certain clubs are accessed by a lot of different users, then you will probably be better off caching each piece.
If you have memcached already set up, I would recommend just separating it out and caching each query. It will take a little extra work to invalidate the correct caches when data changes, but caching is a good idea for performance either way and this gets it in early.
I wouldn’t worry too much about this right now. Premature optimization will just end up costing you a lot of time when you have other things you can get done.
Just get it working and then if you run into performance issues later you can profile your application and focus on optimizing the places that really need it.