Поле в MySQL
 

Хочу создать поле в MySQL для хранения цен в формате типа "22,99"
Вот не знаю какой тип поля указать? FLOAT чтоли? А длинну какую тогда?
Может быть специальный тип есть?

пофиг сделал FLOAT...

shuron
Если все цены будут с точностью до двух сотых максимум, то лучше всего делать INT и хранить там цену*100, т.е. не 10.23, а 1023, а при добавлении/получении из базы корректировать.

ясно... но где ты был раньше:):p

А чем INT лучше чем FLOAT? Экономишь байт?

Гм?... DECIMAL(M,D)?

aleksand
Это во-первых. Что уже не мало. Во-вторых, увеличивается скорость обработки.
medved2002
и?

В смысле целое число быстрее выбирается из таблицы? Сомнительно.
А потом, потеря времени что бы каждый раз домножать на 100, и отбрасывать дробную часть, а потом делить на 100?

гмм. ну вроде как FLoat храниться в упакованом виде. (Decimal нет, храниться как строка.)

И именно этот тип советуют использовать для таких вещей.

medved2002
Не спорю. Но представляются Integer и Decimal в MySQL одинаково - как строки, с той разницей, что Integer не ограничен заданными в структуре таблицы размерами, а Decimal не может выходить за их пределы. Так что нужно уж выбирать в каждом конкретном случае, что требуется.

Гмммм. Поподробнее о том что int не ограничен размерами?

medved2002
MySQL Manual

Не поленился посмотреть. INT и FLOAT занимают одинаково 4 байта, и хранятся, понятно, в бинарном виде. Так что никакой экономии.
DECIMAL и NUMERIC хранятся как строки. Соответственно места требуют намного больше.
http://www.mysql.com/doc/en/Storage_requirements.html

Если ты имеешь ввиду то что в поле DECIMAL(5,2) запихать 123,123 то 3 обрежеться? дык и у тебя тоже самое будет ибо ты жестко зафиксировал что умножать на 100

Если ты про то что надо четко прописывать разрядность числа дык что нам мешает прописать максимально возможный вариант?

medved2002
Я имею в виду, что если запихать в поле DECIMAL(3,2) значение 12345, то получим 999.99

Если не хотим максимальное тогда конечно лучше float.

Итак, как говорил товарищ Кент Бек, "если в чем-то сомневаетесь - спросите об этом компьютер". Посему, дабы подвести итоги диалогу и заодно публично и аргументированно посыпать голову пеплом по отдельным вопросам 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 проигрывает по большинству пунктов.

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

хм... ждем результатов..
принимаем ставки...
я уже сделал Float, так на него и поставлю

Да, вот аттач с исходниками, при редактировнии сообщения новый файл не прицепляется 8(

из-за 0.1 секунды в Int переделывать не буду.. потому что у меня там нагрузка не большая пока на страничке с этим и работает нештяк и так..
ти работать будет дай бог с с загрузкой в 2000 цен.
но пятёрку ты заработал!!:yees:

shuron
Так понятно, что вообще все это имеет смысл только для приложений с большим объемом обрабатываемых данных. Я не думаю, что у тебя такое 8)

PS оффтоп: ты же мне ставил уже пятерку, мне вторая не прибавится 8)))

Настройки мускула какие?

medved2002
default

тфу ну может трой ка прокатит:)) или не пробовать:))

shuron
какая "трой ка"? и для чего прокатит?

ладно забудь.. штука была