Вопрос по типу данных Float

← →
ksa2002 (2004-12-21 12:51) [0]

Вопрос в следующим при вводе числа вида 2,2 через ХП в базе оно записалось как 2,2000004786 или что то подобное , можно ли сделать так что бы оно записывалось такое же как и при вводе (2,2) или придёться форматировать при ввыводе значение ?

← →
dolmat (2004-12-21 12:57) [1]

можно использовать numeric(кол разрядов,точность) или decimal(кол разрядов,точность)

← →
ksa2002 (2004-12-21 12:59) [2]

спасибо ...щаз проверю

← →
Term (2004-12-21 12:59) [3]

если хочеш хранить деньги не используй флоат, почитай про точность, лучше нумерик используй

← →
sniknik © (2004-12-21 13:03) [4]

замени на тип currency/money (или чтото подобное, BCD поля поддерживаются?), частично и DOUBLE PRECISION тоже решит (у него толчность больше).

← →
ksa2002 (2004-12-21 13:03) [5]

нет..... мне максимум сотые понадобяться

← →
msguns © (2004-12-21 13:04) [6]

При работе с float надо всегда использовать округления. Особенно при сравнениях. Иначе может получиться, что 1<>1.

>Term (21.12.04 12:59) [3]
Не всегда это решение оптимально. Например, при проектировании складского учета со средневзвешенными ценами определить заранее, сколько надо дес.разрядов в цене (и НДС в цене) бывает невозможно. В этих случаях Float "убивает всех зайцев"

← →
Zacho © (2004-12-21 13:07) [7]

msguns © (21.12.04 13:04) [6]

Дополню: только не FLOAT, а DOUBLE PRECISION

← →
ksa2002 (2004-12-21 13:08) [8]

а как округлить флоат ? (какой командой)

← →
msguns © (2004-12-21 13:11) [9]

>Zacho © (21.12.04 13:07) [7]
>Дополню: только не FLOAT, а DOUBLE PRECISION

Конечно, конечно, только вот надо было это рассказать это разработчикам компонент Дельфи, в частности тем, кто строгал класс TField. Да и не только им..

← →
Term (2004-12-21 13:11) [10]

а почему бы тогда не использовать

> currency/money
2msguns или тут свои тонкости, если есть расскажи чтобы знать
но он вроде знает

> нет..... мне максимум сотые понадобяться

← →
Zacho © (2004-12-21 13:12) [11]

ksa2002 (21.12.04 13:08) [8]

Используй UDF. Напиши сам или возьми готовую. Их есть много :) См. http://www.ibase.ru/develop.htm раздел User Defined Functions

← →
Zacho © (2004-12-21 13:14) [12]

msguns © (21.12.04 13:11) [9]

Эээ.. Не понял.. Подробнее можно ?
Просто я никогда не использовал FLOAT, а с DOUBLE PRECISION вроде бы всё нормально. Если ошибаюсь, хотел бы узнать в чём.

← →
ksa2002 (2004-12-21 13:15) [13]

воспользовался numeric ...вполне подошло

← →
Term (2004-12-21 13:17) [14]

> Просто я никогда не использовал FLOAT, а с DOUBLE PRECISION
> вроде бы всё нормально. Если ошибаюсь, хотел бы узнать в
> чём.

присоединяюсь

← →
msguns © (2004-12-21 13:25) [15]

>Zacho ©
>Term (21.12.04 13:17) [14]

С типами филдов прикалываетесь, да ? Типа проверка на вшивость ?;))

ЗАДРАЛ Internal Server Error !!!!!!!!!!

← →
Term (2004-12-21 13:46) [16]

да не вшивость и даже не блохастость :)))))
просто если есть инфа хотелось бы услышать

← →
Term (2004-12-21 13:47) [17]

да не вшивость и даже не блохастость :)))))
просто если есть инфа хотелось бы услышать

Float - относится к приблизительным типам данных.
А по теме, если мало ли, относится к деньгам, то используй тип money, такого не будет.

> msguns © (21.12.04 13:25) [15] [Новое
>сообщение][Ответить]
> С типами филдов прикалываетесь, да ? Типа проверка на
> вшивость ?;))

Да нет, никаких приколов, просто действительно хотелось бы более подробно насчёт поста msguns © (21.12.04 13:11) [9]. Серьёзно, интересно. Может я чего не понял.. Или не так понял ... :) Мне правда интересно, какие проблемы могут быть с FLOAT или DOUBLE PRECISION в Дельфи.

> ЗАДРАЛ Internal Server Error !!!!!!!!!!

Пользуйся каким-либо клиентом :)

← →
Term (2004-12-21 14:27) [20]

> Пользуйся каким-либо клиентом :)

хде взять??? ссылку можно????

>Zacho © (21.12.04 14:07) [19]

Ну если так..
Дело в том, что существует "разноголосица" в типах данных как между различными серверами, так и средами прогр-я (языками). Например, в IB по сути есть FLOAT (тип 10) и "все остальные" : DP,Num,Dec (тип 27). Разница только в SCALE. MONEY нет как класса !
В парадоксе или dbf другая классификация.
Кроме того, различные движки используют свои "прибамбасы", особенно универсальные типа BDE. При обмене с конкретными серверами они (движки) знают об этом расхождении и делаю приведения "своих" типов к "серверным".
Ну и, как финал, свои же "штучки" у компонент, в частности, у борландовского класса TField.DataType, рассчитанного, очевидно, "под все, что возможно".

В итоге иногда имеем неожиданные "выверты", когда данные ведут себя не так, как мы от ниж того ждем. Самый характерный пример - Дата. Есть такой тип в Field (dtDate), но его нет, например, в Интербэйзе ! Вообще ! Там есть DateTime, что совсем не одно и то же ! В результате выборка по дате (без указания времени) не возвращает ни одной записи из таблицы, где этих записей м.б. туева хуча ! Похожие фокусы наблюдаем и с Float. Например, пишем INSERT INTO TABLE (.. QUONT) VALUES (..,1.545)
Затем даем
SELECT * FROM TABLE WHERE QUONT=1.545 и что получаем ?
Правильно - 0 записей !!!

Ессно, если в проге заложена логика, где идет анализ "флоатных" данных (например, сравнение или сопоставление с какими-то критичными значениями), то сплошь и рядом она "не работает", если числа сравниваются без округления.

Можно ли обойтись без Float ? Далеко не всегда. У них есть ряд существенных преимуществ:
- компактность (4 байта вместо 8), что очень критично для замерных БД, хранящих офигительное к-во записей и полей именно этого формата
- высокая точность как в одну (целые), так и в другую (дробь) стороны, что весьма критично даже для некоторых учетных задач типа упомянутого мною складского учета (особенно для МБП и материалов). Мне приходилось писать прогу для раскрутки сделки бригадным методом, где в расценках учитывались стотысячные доли копейки !. При этом суммы начислено составляли сотни миллионов (дело было в 94-м), т.е. разброс был туда-сюда по дес.шкале офигительный ! Никакой "моней" здесь, ессно, не катил.

Уф, получилось несколько длинно и запутанно. Тем более, что вряд ли что-то новое вам сказал. Но раз просили..

msguns © (21.12.04 15:53) [21]

Разреши позанудствовать и попридераться :)

Собственно, я хотел услышать твои претензии к классу TField, и вовсе не ради каких-либо "приколов", мне (и думаю, что не только мне) действительно интересно (и полезно) было бы узнать о возможных проблемах с TField. Но проблемы, описанные в msguns © (21.12.04 15:53) [21] никакого отношения собственно к TField не имеют. Так что вопрос остаётся в силе.

А теперь, как и обещал, мелочные придирки ;)

> Дело в том, что существует "разноголосица" в типах
> данных как между различными серверами, так и средами
> прогр-я (языками).

Согласен. Но если говорить о IB и Дельфи, то FLOAT и DOUBLE PRCISION в IB полностью соответствуют Single и Double в Дельфи.

> Например, в IB по сути есть FLOAT (тип 10) и "все
> остальные" : DP,Num,Dec (тип 27). Разница только в
> SCALE

Ну, даже в диалекте 1 это не совсем так, а в диалекте 3 это совсем не так - NUMERIC и DECIMAL не имеют никакого отношения к DP.

> MONEY нет как класса !

Чем NUMERIC не годится на роль MONEY ? Естественно, в диалекте 3.

> Есть такой тип в Field (dtDate), но его нет, например,
> в Интербэйзе ! Вообще !

Уже лет пять как есть :) C тем, что написано далее - полностью согласен, но причём здесь TField ?

> Мне приходилось писать прогу для раскрутки сделки
> бригадным методом, где в расценках учитывались
> стотысячные доли копейки !. При этом суммы начислено
> составляли сотни миллионов (дело было в 94-м), т.е.
> разброс был туда-сюда по дес.шкале офигительный !

Вот именно для таких случаев FLOAT в IB не подойдёт - у него точность всего 7 знаков. Просто не влезут в него миллионы с пятью знаками после запятой. Собственно, это я и имел в виду в [7], советуя DOUBLE PRECISION.

> Тем более, что вряд ли что-то новое вам сказал

Для новичков, думаю, весьма полезная информация.

>Zacho © (22.12.04 10:45) [22]

По поводу Field. Не знаю, что нового хотел ты услышать об особенностях этого класса. Я лишь говорил о том, что типы данных, определенные в этом классе св-вом DataType не совсем соответствуют тем типам, которые представлены, к примеру, стандартами SQL. Смотрим, какие типы данных предлагает нам это св-во (привожу только числовые):

TSmallIntField TFloatField TAutoIncField TFMTBCDField
TBCDFieldT IntegerField TBytesField TWordField
TCurrencyField TLargeintField

а теперь методы (AsXXX):
AsInteger, AsFloat, AsBCD, AsCurrency

Заметь, ни слова о "двойной" (DOUBLE) точности !
Вот тут-то и неувязочка. Т.е. для того, чтобы мне явно указать тип данных для преобразования или операции сравнения/присвоения приходится обходиться вышеперечисленными 4-мя св-вами класса TField, в то время как "родных" представлений у меня может быть значительно больше !
Как мне прикажешь "примазать" к филду тот же самый Extended ?
И где, например, гарантия, что при юзании ftCurrency у меня не обрежутся (округлятся) младшие доли копеек ?
Поэтому я использую для любых дробных чисел тип ftFloat как гарантированный способ получить число с достаточной для меня точностью.
Вот это я и имел в виду, делая пост [9], так тебя заинтриговавший ;)

>Вот именно для таких случаев FLOAT в IB не подойдёт - у него точность всего 7 знаков. Просто не влезут в него миллионы с пятью знаками после запятой. Собственно, это я и имел в виду в [7], советуя DOUBLE PRECISION.

Ты не совсем врубился в приведенный мною пример с расчетом сделки ;)
Речь там шла о том, что наряду с числами огромными (сотни миллионов) присутствовали и числа маленькие, с сотыми долями копеек. Напрмер, некоторые расценки вводились еще "советские" (расчет делался для строительных бригад), т.е. типа 1,5467 р.
Помноженные на различные коэффициенты, эти расценки получали те самые сотые тысячных копеек. Ессно, когда все это умножалось на инфляционные коэффициенты, кол-во, нормы и т.д., получались сотни тысяч. При этом результат округлялся даже не до рублей, а до тысяч. Т.е. в проекте была потребность хранить в одном и том же (грубо говоря) поле числа 2-х видов:
999,999,999.00 и 9.999,999
Вот именно для такого разброса и годится лучше всего именно простой Float

Ребята, не обжайтесь, но вы не с той стороны вопрос начали решать.

Есть такое перифирийное устройство ввода - юзер, которе отвечает ударом по клавишам в ответ на вызов ReadLn();

Все нижеприведенное - мое личное мнение. Я не претендую на роль истины в последней инстанции.

Когда я проектирую базу, я определяю домены (обычно штук 6-8 типов хватает, хотя когда как, бывало и до 20). Это что-то похожее на Делфевые типы данных, в часности есть RDB_FLOAT = DECIMAL(18,3). А все таблицы в базе описаны этими доменами. Дальше, например в справочнике ТОВАРЫ, цена товара - этот тип.
"А если по задаче надо считать сотые копейки ?" - скажет юзер (в начале мы с вами согласились - что это такое переферийное устройство ввода :))) ). Пожалуйста - дробите базовую единицу измерения на более мелкую (например, меряйте товар не в килограммах, а в граммах) - вперед.

И все замечательно работает. есть правда на некоторых предприятиях "завихрения" (в одном кафе учета красного перца ведется в мегатоннах) - ну что тут поделать. ;)))

Конечно, ТАК проектировать базы нельзя, я полностью с этим согласен. Зато геммороя меньше, и поставленную задачу мы тоже этим решаем: "разработать программу и потратить при этом как можно меньше усилий".

Вопрос по типу данных Float Найти похожие ветки