Проектирование таблицы. Как лучше?

2-й вариант тоже позволит хорошо развернуться без создания лишних таблиц.

Так что, я бы выбрал (и выбираю) 2-й.

1. Постройте нормальную логическую модель своей системы. Начните с изучения реляционной модели вообще, почитайте теорию баз данных. Разберитесь что такое "отношения" в принципе и "один-ко-многим", "много-ко-многим" и т.д. в принципе. Сэкономите уйму времени и станете из экспериментатора разработчиком.

2. Выучите хотя бы один язык - английский (предпочтительно) или транслит (на худой конец). Понять что такое в вашей таблице под шифром statys или cout нельзя в принципе, karegory или poradok можно но сложно. Пожалейте программистов которые будут смотреть ваш код или себя, повзрослевшего на пару лет. Стыдно будет.

3. Задумайтесь над тем стоит ли вообще хранить блоки HTML в таблицах.

из-за особенностей mysql тексты действительно лучше хранить в отдельных таблицах, так что второй вариант. и не пренебрегайте другими советами про модель и язык.

что за особенности такие у MySQL, которых нет у других СУБД, которые скажутся на хранении текстов?

реляционная СУБД не место для хранения HTML вообще. они не для этого предназначены.

Религия запрещает HTML в базе держать или есть практические соображения?

"Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время" ☝

stealthy, ну а зачем тогда во всех субд есть типы для текстов и бинарных данных ?

наверняка ведь понадобится постраничная навигация по этим статьям. значит есть потребность в сортировке. при сортировке текстов и блобов mysql не знает сколько нужно памяти под результат и создает временные файлы.

А как Вы сохраните отформатированный текст, введенный пользователем в swying-редакторе? Вырезать будете весь хтмл?

Самый оптимальный в данном случае 2-ой вариант.

Поля называйте так, чтоб сразу можно было понять за что оно отвечает...