Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Изменение типа данных в базе  [new]
Sam_Corhonen
Member

Откуда:
Сообщений: 6
Здравствуйте!
Я разрабатываю приложение, взаимодействующее с БД на SQL Server. Оно работает с числовыми значениями, получаемыми из хранимых процедур базы либо напрямую из таблиц. Некоторые из этих значений дробные и объявлены в базе как float(8). Однако приложение должно точно оперировать с десятичными значениями, чего, как недавно выяснилось, не происходит т.е. еще при извлечении значений из таблиц в хранимой процедуре, а затем и при операциях с ними в той же процедуре значения дробей искажаются, чего быть не должно.
Поэтому я хочу заменить в определениях таблиц тип float на decimal, но это сопряжено с трудностями.

Во-первых, есть мнение, что это может замедлить работу хранимых процедур в базе, а также сильно увеличить объем данных, возвращаемых из процедуры в приложение-клиент. Это важно, поскольку эти данные могут передаваться по сети.
Вопрос: увеличит ли и замедлит ли?

Во-вторых, в базе уже написано множество хранимых процедур, написанных в предположении, что поля объявлены как float. Может быть, потребуется более сложное изменение их текста, чем механическая замена объявлений переменных или временных таблиц с типом float на decimal. В этой конкретной процедуре я такого не увидел, но не факт, что не будет в других. Проверка кода всех процедур и повторное их тестирование слишком затратны по времени.
Вопрос: можно ли точно утверждать, что эти сложные изменения не потребуются и работа хранимых процедур не нарушится?

Заранее спасибо.
9 сен 14, 11:23    [16553294]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Glory
Member

Откуда:
Сообщений: 104760
Sam_Corhonen
Во-первых, есть мнение, что это может замедлить работу хранимых процедур в базе, а также сильно увеличить объем данных, возвращаемых из процедуры в приложение-клиент. Это важно, поскольку эти данные могут передаваться по сети.
Вопрос: увеличит ли и замедлит ли?

float(8) занимает 4 байта
decimal занимает от 5 байтов и выше

Sam_Corhonen
Вопрос: можно ли точно утверждать, что эти сложные изменения не потребуются и работа хранимых процедур не нарушится?

Если вы проведете тестирование, то какие могут быть нарушения ?
9 сен 14, 11:32    [16553344]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Glory
Member

Откуда:
Сообщений: 104760
Sam_Corhonen
Однако приложение должно точно оперировать с десятичными значениями, чего, как недавно выяснилось, не происходит т.е. еще при извлечении значений из таблиц в хранимой процедуре, а затем и при операциях с ними в той же процедуре значения дробей искажаются, чего быть не должно.

Ничего там не искажается.
Просто вы наверное не знакомы с арифметикой чисел с плавающей запятой.
9 сен 14, 11:40    [16553401]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Sam_Corhonen
Member

Откуда:
Сообщений: 6
Glory
float(8) занимает 4 байта
decimal занимает от 5 байтов и выше

Во-первых, float(8), как очевидно следует из названия, занимает 8 байт, что подтверждается средой SSMS.

Glory
Если вы проведете тестирование, то какие могут быть нарушения ?

Во-вторых, я русским языком написал, что тестирование проводить долго, поэтому и возник этот вопрос.

Glory
Ничего там не искажается.
Просто вы наверное не знакомы с арифметикой чисел с плавающей запятой.

И в-третьих, я не пришел бы с вопросом на форум, если бы у меня "ничего не искажалось", тем более что 1 хранимая процедура, в которой для эксперимента поля float были заменены на decimal, демонстрирует правильные результаты. Кроме того, я знаком с арифметикой чисел с плавающей запятой, и мои знания подтверждаются документацией SQL Server, которая говорит о том, что не следует использоваить тип float для хранения точных десятичных значений, так как могут возникнуть погрешности.

Исходя из вышесказанного, у меня к Вам вопрос: Какого хрена вы вообще полезли в эту тему, если не разбираетесь в вопросе? Научитесь сначала читать внимательно и изучите предмет, вот тогда сможете что-то высказывать.

2everyone:
Предыдущие ответы относятся скорее к разряду флуда, поэтому я по прежнему нуждаюсь в помощи. Кто знает ответы?
9 сен 14, 15:03    [16554723]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Glory
Member

Откуда:
Сообщений: 104760
Sam_Corhonen
Во-первых, float(8), как очевидно следует из названия, занимает 8 байт, что подтверждается средой SSMS.

Во-первых, надо читать официальный хелп

Sam_Corhonen
Во-вторых, я русским языком написал, что тестирование проводить долго, поэтому и возник этот вопрос.

Во-вторых, никому, кроме вас, не нужно, чтобы у вас все работало.

Sam_Corhonen
И в-третьих, я не пришел бы с вопросом на форум, если бы у меня "ничего не искажалось", тем более что 1 хранимая процедура, в которой для эксперимента поля float были заменены на decimal, демонстрирует правильные результаты.

В-третьих, если вы не в состоянии получить правильные результаты, то это не знаит, что виноват тип данных float.

Сообщение было отредактировано: 9 сен 14, 15:08
9 сен 14, 15:08    [16554758]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Volochkova
Member

Откуда:
Сообщений: 2321
В свое время в старых базах хранили все цены, суммы в копейках.
Была константа, которая оказывала сколько точек после запятой, точность расчетов по базе.
В итоге все расчеты приводились к операциям - операциям целого числа, а итоговые уже выводились одной функцией, которая делила на 100 например, но только итоговый результат.

Убивалось 2 зайца - Int хранить дешевле по месту, умножать и суммировать проще, не требовался в те времена - сопроцессор.

Возможно Вам этот пример из прошлого поможет.
9 сен 14, 15:36    [16554957]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Sam_Corhonen
Member

Откуда:
Сообщений: 6
Увы, не поможет. Хотя бы потому, что множество кода, как в базе, так и в приложении уже написано в расчете на то, что в базе лежат готовые дробные значения, и делить их ни на что не нужно.
9 сен 14, 15:45    [16555042]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
VGalamakh
Member

Откуда: Киев (Альба)
Сообщений: 66
Volochkova
В свое время в старых базах хранили все цены, суммы в копейках.
Была константа, которая оказывала сколько точек после запятой, точность расчетов по базе.
В итоге все расчеты приводились к операциям - операциям целого числа, а итоговые уже выводились одной функцией, которая делила на 100 например, но только итоговый результат.

Убивалось 2 зайца - Int хранить дешевле по месту, умножать и суммировать проще, не требовался в те времена - сопроцессор.

Возможно Вам этот пример из прошлого поможет.


Сели как-то на грабли с такой схемой...
Цена в копейках умноженная на количество превысила величину допустимого значения int.
9 сен 14, 16:49    [16555580]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Wlr-l
Member

Откуда:
Сообщений: 522
VGalamakh, Ты в каких единицах получаешь зарплату?
В миллиардах!
И сколько получил в последний раз?
200 наномиллиардов.
9 сен 14, 17:07    [16555705]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Jovanny
Member

Откуда:
Сообщений: 1195
Sam_Corhonen
Glory
float(8) занимает 4 байта
decimal занимает от 5 байтов и выше

Во-первых, float(8), как очевидно следует из названия, занимает 8 байт, что подтверждается средой SSMS.

MSDN
float [ (n) ]

Где n — это количество битов, используемых для хранения мантиссы числа в формате float при экспоненциальном представлении. Определяет точность данных и размер для хранения.
Значение параметра n должно лежать в пределах от 1 до 53.
Значением по умолчанию для параметра n является 53.

Значение nТочностьОбъем памяти
1-247 знаков4 байта
25-5315 знаков8 байт


9 сен 14, 17:52    [16555966]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
prog123
Guest
Volochkova
В свое время в старых базах хранили все цены, суммы в копейках.
Была константа, которая оказывала сколько точек после запятой, точность расчетов по базе.
В итоге все расчеты приводились к операциям - операциям целого числа, а итоговые уже выводились одной функцией, которая делила на 100 например, но только итоговый результат.

Убивалось 2 зайца - Int хранить дешевле по месту, умножать и суммировать проще, не требовался в те времена - сопроцессор.

Возможно Вам этот пример из прошлого поможет.


Самое точное будет BigInt - для целой части, и BigInt - для дробной отдельно. Дешево и сердито.:) Не скоро устареет.
9 сен 14, 18:03    [16556034]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Jovanny
Member

Откуда:
Сообщений: 1195
Sam_Corhonen
Во-первых, есть мнение, что это может замедлить работу хранимых процедур в базе

Маловероятно.
Sam_Corhonen
а также сильно увеличить объем данных, возвращаемых из процедуры в приложение-клиент

А Вы что, передаёте в клиентскую часть гигабайтные массивы данных?
9 сен 14, 18:06    [16556052]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Jovanny
Member

Откуда:
Сообщений: 1195
prog123
Volochkova
В свое время в старых базах хранили все цены, суммы в копейках.
Была константа, которая оказывала сколько точек после запятой, точность расчетов по базе.
В итоге все расчеты приводились к операциям - операциям целого числа, а итоговые уже выводились одной функцией, которая делила на 100 например, но только итоговый результат.

Убивалось 2 зайца - Int хранить дешевле по месту, умножать и суммировать проще, не требовался в те времена - сопроцессор.

Возможно Вам этот пример из прошлого поможет.


Самое точное будет BigInt - для целой части, и BigInt - для дробной отдельно. Дешево и сердито.:) Не скоро устареет.

Да, зря Microsoft старался, придумывая тип money. :)
9 сен 14, 18:08    [16556062]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
VGalamakh
Member

Откуда: Киев (Альба)
Сообщений: 66
Wlr-l
VGalamakh, Ты в каких единицах получаешь зарплату?
В миллиардах!
И сколько получил в последний раз?
200 наномиллиардов.


Не про зарплату шла речь а про отгрузку товара

declare @uprc int=100000 --1000 рублей в копейках
declare @soqs int=100000 --100 000 штук

Select @uprc*@soqs
9 сен 14, 18:31    [16556161]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Volochkova
Member

Откуда:
Сообщений: 2321
VGalamakh
Wlr-l
VGalamakh, Ты в каких единицах получаешь зарплату?
В миллиардах!
И сколько получил в последний раз?
200 наномиллиардов.


Не про зарплату шла речь а про отгрузку товара

declare @uprc int=100000 --1000 рублей в копейках
declare @soqs int=100000 --100 000 штук

Select @uprc*@soqs

Решение было очень простое, вводился товар кратный 1000 штук и отгружался.
Кому то помогало, причем очень.
В те времена Пень 3, 1000 было в диковинку :-)


prog123
Volochkova
В свое время в старых базах хранили все цены, суммы в копейках.
Была константа, которая оказывала сколько точек после запятой, точность расчетов по базе.
В итоге все расчеты приводились к операциям - операциям целого числа, а итоговые уже выводились одной функцией, которая делила на 100 например, но только итоговый результат.

Убивалось 2 зайца - Int хранить дешевле по месту, умножать и суммировать проще, не требовался в те времена - сопроцессор.

Возможно Вам этот пример из прошлого поможет.


Самое точное будет BigInt - для целой части, и BigInt - для дробной отдельно. Дешево и сердито.:) Не скоро устареет.

В то время bigint был только в мечтах. Это был как вариант "проверки ускорения".
Поможет или нет.
10 сен 14, 05:43    [16557270]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Sam_Corhonen
Member

Откуда:
Сообщений: 6
Не так написал. Я имел в виду обычный float, он же float(53), который занимает 8 байт.
Что касается типов, то decimal или money - не суть важно, главное для меня - как это повлияет на производительность. Если точность и масштаб decimal будут таковы, что его объем составит, скажем, 13 байт, не замедлит ли это работу функций?
10 сен 14, 11:29    [16558134]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Glory
Member

Откуда:
Сообщений: 104760
Sam_Corhonen
Если точность и масштаб decimal будут таковы, что его объем составит, скажем, 13 байт, не замедлит ли это работу функций?

Вы серьезно думаете, что на производительность функции сильно повлияет разница выходного параметра в 5 байт ?
10 сен 14, 11:38    [16558202]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
VGalamakh
Member

Откуда: Киев (Альба)
Сообщений: 66
Volochkova
Решение было очень простое, вводился товар кратный 1000 штук и отгружался.
Кому то помогало, причем очень.
В те времена Пень 3, 1000 было в диковинку :-)


Ну не все так просто ведь )
а)Отгружали медикаменты - по закону можешь отгружать только то, что зарегистрировано. Поэтому ввести кратный товар не имели возможности.

б) При "товар кратный 1000" - будет и цена кратна 1000

в)А если следовать по-этому пути, то пришлось бы дробить строки на этапе ввода заказа, т.е. заказали 1500 шт например - надо делать заказ на 1000 шт и на 500 шт.
10 сен 14, 11:43    [16558261]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Sam_Corhonen
Member

Откуда:
Сообщений: 6
Glory

Повторяю еще раз. Речь идет не о параметрах процедуры, а о полях таблицы, которая может включать не одну тысячу записей, соответственно процедура, обрабатывающая таблицу от начала и до конца, проделывает над полями тысячи операций, а значит несущественная разница в одной операции может превратиться в огромную для целой таблицы.
10 сен 14, 13:27    [16558952]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Volochkova
Member

Откуда:
Сообщений: 2321
VGalamakh
Volochkova
Решение было очень простое, вводился товар кратный 1000 штук и отгружался.
Кому то помогало, причем очень.
В те времена Пень 3, 1000 было в диковинку :-)


Ну не все так просто ведь )
в)А если следовать по-этому пути, то пришлось бы дробить строки на этапе ввода заказа, т.е. заказали 1500 шт например - надо делать заказ на 1000 шт и на 500 шт.


Не так просто, да.
Но когда продажа в 100 миллионов, то есть возможность изгальнуться.
Виртуальная строка была типа шприцы - коробка по 1000 штук, а цена в 1000 рублях.
В документе печатаем не 1000 р, а 1 ( одна тыс рублей) текстом на бумажке.
Ну и т.д. чем дальше дело было не скажу, но виртуально продажи делали или дробили на заказы. Но выкрутиться можно было, когда цена вопроса уже за милльоны переходила.
10 сен 14, 13:58    [16559195]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
invm
Member

Откуда: Москва
Сообщений: 9413
Sam_Corhonen
Повторяю еще раз. Речь идет не о параметрах процедуры, а о полях таблицы, которая может включать не одну тысячу записей, соответственно процедура, обрабатывающая таблицу от начала и до конца, проделывает над полями тысячи операций, а значит несущественная разница в одной операции может превратиться в огромную для целой таблицы.
Вам еще раз повторят - ответы на ваши вопросы даст только тестирование.
Устранение ошибок проектирования, не убранных в зародыше, всегда трудоемко и дорого.
10 сен 14, 14:19    [16559335]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Glory
Member

Откуда:
Сообщений: 104760
Sam_Corhonen
а о полях таблицы, которая может включать не одну тысячу записей, соответственно процедура, обрабатывающая таблицу от начала и до конца, проделывает над полями тысячи операций,

Какие "тысячи операций с полями" ? данные из таблицы загружаются в память страницами и экстентами.
10 сен 14, 16:32    [16560364]     Ответить | Цитировать Сообщить модератору
 Re: Изменение типа данных в базе  [new]
Jovanny
Member

Откуда:
Сообщений: 1195
Sam_Corhonen
Повторяю еще раз. Речь идет не о параметрах процедуры, а о полях таблицы, которая может включать не одну тысячу записей, соответственно процедура, обрабатывающая таблицу от начала и до конца, проделывает над полями тысячи операций, а значит несущественная разница в одной операции может превратиться в огромную для целой таблицы.

Тут уж Вы выбирайте: либо
Sam_Corhonen
значения дробей искажаются, чего быть не должно.
, либо
Sam_Corhonen
несущественная разница в одной операции может превратиться в огромную для целой таблицы.
10 сен 14, 17:11    [16560632]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить