Question

I recently started working for a fairly small business, which runs a small website. I over heard a co worker mention that either our site or MySQL databases get hit ~87 times a second.

I was also tasked today, with reorganizing some tables in these databases. I have been taught in school that good database design dictates that to represent a many-to-many relationship between two tables I should use a third table as a middle man of sorts. (This third table would contain the id of the two related rows in the two tables.)

Currently we use two separate databases, totalling to a little less than 40 tables, with no table having more than 1k rows. Right now, some PHP scripts use a third table to relate certain rows that has a third column that is used to store a string of comma separated ids if a row in one table relates to more than one row in some other table(s). So if they want to use an id from the third column they would have to get the string and separate it and get the proper id.

When I mentioned that we should switch to using the third table properly like good design dictates they said that it would cause too much overhead for such small tables, because they would have to use several join statements to get the data they wanted.

Finally, my question is would creating stored procedures for these joins mitigate the impact these joins would have on the system?

Thanks a bunch, sorry for the lengthy explanation!

Answer 1

By the sound of things you should really try to redesign your database schema.

two separate databases, totalling to a little less than 40 tables, with no table having more than 1k rows

Sounds like it’s not properly normalized – or it has been far to aggressively normalized and would benefit from some polymorphism.

comma separated ids

Oh dear – surrogate keys – not intrinsically bad but often a sign of bad design.

a third table to relate certain rows that has a third column that is used to store a string of comma separated ids

So it’s a very long way from normalised – this is really bad.

they said that it would cause too much overhead for such small tables

Time to start polishing up your resume I think. Sounds like ‘they’ know very little about DBMS systems.

But if you must persevere with this – its a lot easier to emulate a badly designed database from a well designed one (hint – use views) than vice versa. Redesign the database offline and compare the performance of tuned queries – it will run at least as fast. Add views to allow the old code to run unmodified and compare the amount of code you need to performa key operations.