I finally got around to looking at the URL you gave for the "Toxi" scheme.
In case you didn't notice, "Toxi" is just the name (or handle) of a *PERSON* who submitted that scheme to the author of that page.
The page is, quite frankly, ridiculous.
Just for starters, he doesn't address the *HUGE* disadvantage that his "SQLlicious" scheme has. To wit: It CAN NOT take advantage of INDEXES. (It could do so using full text indexes, but those have problems of their own, such as finding matches where none exist, because they treat various forms of a word as the same as the main word.)
It's essentially a useless scheme. ANY good database design book will warn you away from it.
You seem enamored of the second scheme there, the "Scuttle" solution. I've already given my opinion of it. ANY CHANGES you may make in the future *WILL* require changes to your database schema. And to all the code you use to access the database. And... Again, if you really are 100% confident that you are never never going to change how things work, then this method could work.
But I 100% agree with Felgall: The *ONLY* excuse for using this is if you find, via EXTENSIVE testing and benchmarking, that there are potential problems in the normalized scheme *AND* the unnormalized version performs significantly better. To me, here "significantly" would need to be at least one-third faster and I'd rather see at least one-half faster. Again, your tests and benchmarks should include variations in the indexes used. That is, make sure you are using the best indexes you can for MySQL.
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.