[Saruman]

Итак, как говорил товарищ Кент Бек, "если в чем-то сомневаетесь - спросите об этом компьютер". Посему, дабы подвести итоги диалогу и заодно публично и аргументированно посыпать голову пеплом по отдельным вопросам 8), я решил просто написать несколько тестов и проверить вопросы производительно для различных типов данных на опыте.
Использовалось: PHP 4.3.3, MySQL 4.0.15, ОС WinXP Pro SP1, комп Intel P4 2.4 GHz, 512 Mb RAM.
Тестировалась скорость обработки данных при их хранении в форматах: INT(5), DECIMAL(5,2), FLOAT.
Исходники тестов для интересующихся - в аттаче, структуру таблиц можно увидеть в коде.
Методика:
1. Забиваем в таблицу 100000 записей со случайными значениями.
2. Делаем UPDATE для половины записей.
3. Делаем SELECT другой половины.

Во время каждого из шагов замеряем время, потраченное на него. Плюс, как побочный эффект, наблюдаем размер баз.

Результаты.

1. Размер баз после полного заполнения (завершения шага 1).
Integer - 900000 байт,
Float - 900000,
Decimal - 1100000.

Так что я был неправ насчет экономии - извиняюсь. Поклон в сторону aleksand.

2. Поехали по времени работы. Шаг 1 - INSERT.
Integer - 46.563 секунд,
Float - 45.589,
Decimal - 46.702.
Как видим, на данном этапе формат практически не имеет значения.

3. Шаг 2 - UPDATE.
Integer - 0,227,
Float - 0.237,
Decimal - 0.658.
Integer и Float отработали почти в 3 раза быстрее Decimal. В принципе, результат можно понять, если вспомнить, что Int и Float хранятся в упакованном представлении, а Decimal - суть строка. Ок, едем дальше.

4. Шаг 3 - SELECT.
Integer - 2,045,
Float - 2.175,
Decimal - 2.179.
А вот это уже интересно. Float и Decimal отработали за одно и то же время, при том, что для Float я использовал округление в виде ROUND(value, 2), чтобы уравнять получаемые результаты. Integer при вызове делился на 100 и оказался быстрее других типов. Ненамного, но все же 0.1 секунды при общем весе 2 секунды иногда имеет значение. Хотя остается под вопросом, почему Float и Decimal работали одно и то же время при явной разнице в предыдущем тесте. Как гипотезу могу предложить тот факт, что при добавлении числа к полю типа Decimal MySQL требуется выполнять приведение типов, что и сказывается на производительности. Но, конечно, возможны и другие причины.

Текущие выводы: нужно планировать, какая из операций будет наиболее часто использоваться в приложении (и время какой может быть критичным), и исходя из этого выбирать тип полей для хранения. Но объективно Integer все же имеет небольшой выигрыш по сравнению с остальными полями, несмотря на необходимость умножать/делить на 100 при работе. Decimal проигрывает по большинству пунктов.

Комментарии/предложения/пожелания приветствуются в аргументированном виде. Можно также указать, где я показал себя ламером, но опять же аргументированно.