Вложенные теги form

Недавно столкнулся с такой ситуацией, когда случайным образом у меня в php-коде получилась вложенная одна в другую форма. Причем часть полей input пропала после отправки (submit). Я не понимал в чем дело, но потом меня осенило и я задал себе вопрос "Бывают ли вложенные формы?".
Поискал в яндексе, на многих сайтах говорят что:

HTML-документ может содержать в себе несколько форм, однако формы не должны находиться одна внутри другой.

Я этому не поверил, рассуждая по принципу "подобия": если все парные теги могут быть
вложенными(table,b,p,font,...,etc.), то почему нет такого свойства у тега form.
Решил заглянуть в "источники" на w3c.org и ничего похожего не нашел по вложенным формам.
Примечатьльно, что в спецификации XHTML предпологается, что формы должны быть контейнерами для различных мульти-медийных, поисковых и прочих элементов, наряду с обыкновенными полями, так почему не разработать схему вложенных форм?

Не используйте условия IF в MySQL запросах

При изучении почти всех языков, начинающим разработчикам говорят: "не используйте абсолютные переходы goto", кроме языка Perl, что означает "старайтесь не использовать" или
"используйте, но крайне редко". Тоже я могу сказать и про IF в MySQL: "старайтесь не использовать конструкцию IF в MySQL запросах".
Разрабатывая внутреннюю программу для фирмы на php+mysql в силу обстоятельств мне пришлось прибегнуть к такой конструкции при запросе в MySQL:


SELECT
t1.*, t2.*, t3.*
FROM
t1, t2, t3
WHERE
IF (t1.field1 = 0,
t1.field2 = t3.field2,
t1.field3 = t2.field3
)
GROUP BY t1.field3
ORDER BY DESC



Что, на первый взгляд, спасало положение, но я проверял это на 5, максимумна 10 записях в таблице. При введение в эксплуотацию этого кода при количестве записей 200 и выше, сервер MySQL просто "вешался". Страница генерировалась от 60 до 250 секунд. Сначала я грешил что я использую слишком много запросов в внешней базе данных на другом хосте, но даже исключение этих запросов не помогло.
Как я понял дело заключается в механизме IF, т.е. код просит пройти все записи таблицы t1, где поле field1 = 0
и выбрать данные или из t2 или из t3. Получается очень долгий запрос.
Пришлось потратить больше времени и переделать структуру программы. Еще раз прихожу к выводу, что нельзя экономить на времени проектировании проекта, но это уже другая тема.

Переход к другой кодировке на MySQL 5.X

Передо мной встала задача перейдти к другой кодировке в рабочей базе данных MySQL.
Первоначально данные хранились в MySQL 4.Х, но после перехода к MySQL 5 версии данные были внесены в кодировке UTF-8. Причем в MySQL 5 появилась параметр "сравнение", по умолчанию значение которого равно "latin1".

$ mysqldump database_name -uroot -p > base.sql
Установка konwert:
$ apt-get install konwert
Смотрим список доступных фильтров:
$ ls /usr/share/konwert/filters/
Конвертируем:
$ konwert UTF8-cp1251 base.sql -o base-1.sql
Конвертацию под windows можно сделать с помощью программы Штирлиц.
Заменяем текущую кодировку на нужную:
$ cat base-1.sql | awk '{gsub(/latin1/,"cp1251");print}' > base-1251.sql
где latin1 - текущая кодировка БД, cp1251 - новая кодировка.
Тоже самое можно сделать в любом редакторе простой заменой.
И результат заносим в нашу базу:
$ mysql -uroot -p -d database_name