Comments on: More then 1000 columns – get transactional with TokuDB

By: Reiner Rusch

Reiner Rusch — Fri, 26 Sep 2014 19:11:20 +0000

Yes, ths problem is very common.
The point is to learn from this and not to teach others doing same mistakes again and again.
As a dba I see such things directly and it’s amazing what you could get out of an old machine by optimizing instead of just buying a newer one and to hope this would solve a problem (for a long term…)! 😉

And yes, there’s a gap between what you are told in school about normalization and what your application afforts in real.
This problem increases while more and more application uses the table in different ways.
My solution is to measure and profile events again and again….!

By: Przemysław Malkowski

Przemysław Malkowski — Fri, 26 Sep 2014 19:00:33 +0000

In this case the real reason to use over 1000 columns was just an old application which still has to be used but is not going to be changed as it’s development life time has finished. I think this is quite common problem.
On the other hand, I can imagine a very specific sensible use case when some scientific objects have thousands of properties, though indeed this would not be a common one at all 🙂
My point was that it is great that we have this kind of choice in MySQL – for some cases InnoDB fits just great, for others TokuDB may be better (with “real” reasons, like excellent compression, disk IO bound workloads, etc).

By: Reiner Rusch

Reiner Rusch — Fri, 26 Sep 2014 17:06:30 +0000

I would say the problem is more historical and was made wrong just from the beginning.
What is a real fact which forces to use a 1000 column table???