Страница 1 из 1

Перевод вещественных чисел в строку и не значащие нули

Добавлено: 18 апр 2005, 11:28
О.Д.Н.
К примеру создаю такие таблицу и представление:

Код: Выделить всё

CREATE TABLE SALE (
       ID INTEGER NOT NULL,
       M21 NUMERIC(8,3) DEFAULT 0 NOT NULL,
       M22 NUMERIC(8,3) DEFAULT 0 NOT NULL,
       CONSTRAINT SALE_PK PRIMARY KEY (ID)
);

Код: Выделить всё

CREATE VIEW VIEWSALE(ID,M2)
AS
SELECT S.ID, S.M21 || '/' || S.M22
FROM SALE S
Заполняем таблицу и делаем запрос представлению:

Код: Выделить всё

SELECT * FROM VIEWSALE
Получим что-то подобное:

0 20,123/32,000
1 30,010/56,000
2 11,000/33,000

Можно ли избавиться от не значащих нулей?
Сори за излишнее, может быть, попунктовое расписывание.

Добавлено: 18 апр 2005, 13:38
kdv
что значит "избавиться"? А если там будут не нули? Хочешь, приводи по cast к целому. Вообще непонятно, зачем числа приводить к строкам и выводить их в таком виде, а потом "избавляться" от каких-то "нулей" в строках...

Добавлено: 18 апр 2005, 21:46
О.Д.Н.
//что значит "избавиться"?
значит перевести число в строку, так как переводят его большинство компиляторов современных языков программирования - без значащих нулей.

//А если там будут не нули?
то оставлять после запятой, ровно столько, сколько значащих цифр.

Заморочка такая появилась собственно вот от куда: есть БД в которой числа должны храниться именно в таком формате как приведено в таблице, в ту же очередь есть сторонняя фирма которой необходимо порой отсылать данные и у них свои стандарты на это дело.

Добавлено: 18 апр 2005, 22:38
Merlin
О.Д.Н. писал(а)://что значит "избавиться"?
значит перевести число в строку, так как переводят его большинство компиляторов современных языков программирования - без значащих нулей.
Ой. И с каких это пор _компиляторы_ начали по собственному усмотрению переводить числа в строки, интересно? И при этом самостоятельно решать в каком формате? Я что-то упустил в развитии компиляторов? А в какой момент они это делают и зачем? Итереснааа...
О.Д.Н. писал(а): Заморочка такая появилась собственно вот от куда: есть БД в которой числа должны храниться именно в таком формате как приведено в таблице, в ту же очередь есть сторонняя фирма которой необходимо порой отсылать данные и у них свои стандарты на это дело.
Вот и преобразовывать в стандарт сторонней фирмы в приложении, занимающемся подготовкой и отсылкой данных в стороннюю фирму. Указывая компилятору современного языка программирования формат в параметрах вызова используемой функции преобразования. А если делать клиентово на клиенте всё-таки не позволяют религиозные соображения и обязательно надо всё делать прям на сервере, то писать UDF и пользоваться ею. В принципе можно написать и SP, выполняющую эту задачу, но это будет уже вершина проктологии.

Добавлено: 19 апр 2005, 00:49
О.Д.Н.
А вот перевирать меня не надь. Я не говорил, что компиляторы "по собственному усмотрению". А вот негласное преобразование типов эт. пожалуйста.
Только опять же не надо придираться к словам и говорить, что преобразование типов происходит не на уровне компилирования, а на уровне исполнения машинного кода. И раз уж меня начали за подол дергать, то в данном случае наверное уместнее бы было вообще говорить об интерпретаторах?
Perl: print 12.100;
PHP: echo 12.100;
JavaScript: document.write(12.100)


//Вот и преобразовывать в стандарт сторонней фирмы в приложении
собственно я так и хотел сначала сделать пока не выяснилось, что отображение и распечатка информации в таком виде и для непосредственного клиента не помешает, дополнительные же вычисляемые поля у клиента лепить не охота и так машины слабенькие. UDF - действительно не плохая мысль, если штатными способами требуемое не как не сделать :) А хранимые процедуры... - на сколько они сторможают выборку если в них просто напрямую передавать все поля таблицы, не делая ни каких дополнительных вычислений?

Добавлено: 19 апр 2005, 02:11
Данилов Юрий
О.Д.Н. писал(а): собственно я так и хотел сначала сделать пока не выяснилось, что отображение и распечатка информации в таком виде и для непосредственного клиента не помешает
Если клиент такой непосредственный - копию ему. В таком же виде.
О.Д.Н. писал(а): А хранимые процедуры... - на сколько они сторможают выборку если в них просто напрямую передавать все поля таблицы, не делая ни каких дополнительных вычислений?
Не сторможают. Только вот зачем из пустого в порожнее - ежели ни каких вычислений, то и select'а хватит.
:P

Добавлено: 19 апр 2005, 12:36
Merlin
О.Д.Н. писал(а): А вот негласное преобразование типов эт. пожалуйста.
А эт шо за зверь? В каком языке можно строку сложить с числом? Я имею в виду из современных высокоуровневых. Про ассемблеры и PL/1 мне рассказывать не надо, кушал в больших дозах. Если всё-таки говорить то, что хочется сказать, то в библиотеке (исполняющей системе) любого транслятора, что в компиляторе, что в интерпретаторе, есть функции форматирования числовых типов при визуализации. И если ты не указываешь формат явно, то внутри функции визуализации вызывается всё та же функция с форматом по умолчанию. Так вот, сервера баз данных не занимаются визуализацией. Они занимаются хранением данных и манипулированием ими. Поэтому развитых функций форматирования не предусмотрено. При передаче числового типа на клмента всегда передаётся информация о типе (в случае numeric-decimal в том числе scale) и внутренне представление. И клиент занимается визуализацией самостоятельно исходя из этих данных и, если ты ему указываешь формат визуализации, то и из него, если нет - формата по умолчанию, который может отличаться от описания типа на сервере. Внутри же сервера при неявных преобразованиях используется только информация о типе. Для экзотики предусмотрен механизм UDF.
О.Д.Н. писал(а):
Вот и преобразовывать в стандарт сторонней фирмы в приложении
собственно я так и хотел сначала сделать пока не выяснилось, что отображение и распечатка информации в таком виде и для непосредственного клиента не помешает, дополнительные же вычисляемые поля у клиента лепить не охота и так машины слабенькие.
Да брось ты, какая там нагрузка на преобразовании, тем более, что оно делается по любому, но с дефолтным форматом. Не массивы же километровые перебирать.
О.Д.Н. писал(а): А хранимые процедуры... - на сколько они сторможают выборку если в них просто напрямую передавать все поля таблицы, не делая ни каких дополнительных вычислений?
Смотря что за выборка. Именно селективные процедуры применяют главным образом когда одним запросом с клиента получить желаемый результат невозможно или очень дорого с точки зрения оптимизатора, выгоднее собрать результат с помощью нескольких запросов внутри For Select по основным таблицам, вызывая на if-ах только те, которые для теукщей записи нужны. Ну и ещё бывают случаи параноидального отношения к управлению доступом. А на тупом простом селекте с минимальной обработкой на лету будет проигрыш, особенно на длинных фильтруемых впоследствии выборках, условия в процедуру проталкивать можно, но в общем случае геморно и нецелесообразно. Клиенту клиентово, серверу серверово. А в данном случае внутри процедуры всё равно придётся пользоваться низкоуровневыми UDF из стандартной библиотеки работы со строками, так что это будет именно через неё, такую круглую, белую, полную :)

Добавлено: 19 апр 2005, 12:53
kdv
дополнительные же вычисляемые поля у клиента лепить не охота и так машины слабенькие.
то есть, число из недр компьютера выводится на экран как число? :)

и вообще, форматирование для того и придумано, чтобы не выводить данные так, чтобы от них можно было сломать глаза. Числа всегда форматируются по "правому краю" и выводятся с фиксированным числом запятых. См. любую бухгалтерскую программу, да или тот же excel.