99% данных в столбце - целые числа. Но иногда туда нужно вставить цену. Пробовал выбирать тип decimal , но тогда ко всем целым числам прибавляется '.0', т.е. добавил '1', а в выводе вылучаю '1.0'. Ну и соответственно нулей столько, сколько указано в параметре типа данных.
А мне нужно чтобы целые были целыми , без преобразований, т.к. обработка тысяч строк с приобразованием дело нехорошее.
Пробовал float , но он все округляет.
Пока остановился на double, но ведь он задимает больше места, да и он с двойной точностью, что наверно не очень хорошо.

Подскажите, пожалуйста, какой тип данных выбрать, какие парамтеры задать?
Числа будут храниться целые(от 0 до 999'999) и нецелые(от 0 до 999'999.99).

Для чего это нужно

miksofttanglirне надо так делать.+1

Но если очень хочется, то можно хранить цену в копейках в целочисленном поле.

Идея хорошая, спасибо.
Не знаю почему тут все так против меня ополчились, я ведь не храню тучную цену для банка, с точностью 100500 знаков после запятой. У меня округленная цена для сайта, где знаков после запятой не более 2х.

Так как некоторые данные целочисленные я их напрямую записываю в характеристики(склад, цена, ...), а там где это длинные строки, дабы не нагружать таблицу, я записываю ссылку на другую таблицу. Соответственно в столбце есть крыжик, который говорит внешние это данные или непосредственные.

В итоге сложные поиски по таблице(с множеством условий и джоинов) работают очень быстро, т.к. я индексирую значения. Если бы в значениях хранились не ссылки а строки varchar длиной 300+, никакого бы индекса не получилось.

Да, если бы точность нужна была бы высокой, без округления, то конечно же я бы хранил цены в отдельной таблице.

Выбрал в конечном счете DOUBLE тип данных. Сравнивал с INT на таблице с 10 млн записей, разницы не оказалось совсем, что весьма удивило, но факт. Конечно же делал обновление кэша и оптимизацию.

К слову, обращения к третьей таблице, в которой хранятся строки, из sql нет, данные разово вытягиваются и сохраняются в кэш далее при выводе используется подстановка значений из кэша, если это внешние данные.

miksoft,

проверял на практике. Собственно изначально структура базы была с хранением данных напрямую, потом как начали выгружать на сайт миллионы товаров возникла эта проблема. А индекс на varchar 300 работает медленней, чем на int 11. И сам индекс получается очень увесистым, там уже появляется проблема нового характера: индекс перестает помещаться в оперативку.

На счет запутанной структуры. А как же сделать правильно? В данном случае все просто: цена и состояние склада хранится напрямую, а прочие данные хранятся в таблице значений. Чем можно заменить эту систему? Я подумал, вариантов придумать не смог - все остальное гораздо сильнее усложняло систему.

В общем-то структура такая же, только вы цены вынесли в отдельную таблицу.
А вот на счет "таблица связей товар-значение характеристики. " не очень понял. Т.е. вы в отдельной таблице храните значение принадлежности характеристики к товару? Почему нельзя использовать "справочник значений характеристик", там хранится характеристика и там же id товара, к которому она принадлежит. Или я что-то не понял?

а, понял, в общем структура получается абсолютно такая же как у меня, только цены в отдельной таблице.

miksoft,
спасибо за разъеснение