Поле в MySQL

[shuron]

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

[shuron]

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

[Saruman]

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

[shuron]

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

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

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

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

[Saruman]

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

Первоначальное сообщение от Saruman
aleksand
Во-вторых, увеличивается скорость обработки.
medved2002
и?

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

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

Первоначальное сообщение от Saruman
и?

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

[Saruman]

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

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

[Saruman]

medved2002
MySQL Manual

The maximum range of DECIMAL and NUMERIC values is the same as for DOUBLE, but the actual range for a given DECIMAL or NUMERIC column can be constrained by the precision or scale for a given column. When such a column is assigned a value with more digits following the decimal point than are allowed by the specified scale, the value is rounded to that scale. When a DECIMAL or NUMERIC column is assigned a value whose magnitude exceeds the range implied by the specified (or defaulted) precision and scale, MySQL stores the value representing the corresponding end point of that range.
...
про integer:
...
This optional width specification is used to left-pad the display of values whose width is less than the width specified for the column, but does not constrain the range of values that can be stored in the column, nor the number of digits that will be displayed for values whose width exceeds that specified for the column.

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

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

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

[Saruman]

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

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

[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 проигрывает по большинству пунктов.

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

[shuron]

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

[Saruman]

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

[shuron]

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