Осталось синус довести до 6:



Результат по центру:

aleks222,

Раз сказал А, скажи и В. Как str поможет выровнять строковое представление числа по центру?

DaniilSeryi,

1.Здесь никто и не ссорится, решаем программистский этюд.

2.Вы не прочли условия задачи, поэтому привели способы форматирования чисел с помощью функции format, но задача-то стоит в эмуляции функций LPAD/RPAD (см. 22322992 ).

3.Вы не увеличили значение синуса, а уменьшили его.

Всю ночь не спал, всё думал, "как мне позор свой искупить"?

1.Выросло поколение программистов, которые не знают, и есть программисты, которые уже забыли, что такое текстовый режим отображения информации.

2.Задача выравнивания данных в запросе может быть вполне реальной, если нужно, например, подготовить файл для его печати на устройстве, которое а) поддерживает текстовый режим и б) в нем можно установить моноширинный шрифт.

3.Главное получить правильный результат, потом его можно улучшать до бесконечности.

4.Выравнивание по левому краю можно выполнить просто:
cast(N as char(10)),
но есть два но а) длину можно задать только константой; б) если нужно проверить результат, то после cast нужно еще заменить пробелы на точки: replace(cast(N as char(10)), ' ', '.'). Попробуйте сосчитать пробелы на экране или на белом листе бумаге, особенно при пропорциональном шрифте.

5.Выравнивание по правому краю целого числа можно выполнить функцией
str(N, @L [, 0]).
Здесь длину можно задать переменной, но а) для того, чтобы пробелы заменить на точки, нужна будет функция replace; б) нельзя выровнять НЕ целые числа и текст.

6. Осталось привести пример.




В L1 функция substring заменена функцию left для большей наглядности. Выражения L1, R1 C1, на мой взгляд, однотипны, подходят к данным любого типа и легко отлаживаются.

1.Вы не прочли условия задачи, поэтому привели способы форматирования чисел с помощью функции format, но задача-то стоит в эмуляции функций LPAD/RPAD (см. 22322992 ).
2.Надо понять, что же все-таки делают функции LPAD и RPAD, которых нет в T-SQL. Если непонятно, то можно взять текстовый редактор и посмотреть, как происходит выравнивание влево, вправо, по центру.
3.Если приводите какие-то примеры из документации, то нужно сначала самому их выполнить и осмыслить результат.
4.Разберем ваш пример, на примере одной культуры с выравниванием влево:




Сравните полученные результаты с эталоном L1. Увидели, что ни один из ваших примеров не решает поставленную задачу?

5.Вы не только уменьшили значение синуса, но и загнали его в отрицательную область.

DaniilSeryi,

Я искренне рад, что вы поняли разницу между форматированием чисел и выравниванием полей, и что я не зря потратил время на эту задачу. Хоть какая-то польза получилась от меня. А тянуться ко мне не обязательно.


Безусловно функция format - полезная функция. Правда строка формата могла бы быть гибче. Например, можно было бы сделать 'N10.3' – под число отводится 10 позиций, из которых одна отводится под разделитель и три под дробную часть, незанятые позиции заполняются пробелами. Или, например, так 'S-12' – под строку отводится 12 символов, строка как есть прижимается влево (ведущие пробелы не удаляются). Если строка короче 12 символов, то она дополняется пробелами. Если длиннее, то обрезается. 'S12' – то же самое, только строка прижимается вправо. Если уж форматировать, то форматировать.

Конечно, можно свалить это на клиента с гридами и с чем-то там еще. Но часто такого клиента просто нет. Нужен обычный текстовый файл. При этом важно, чтобы механизмы выгрузки результата запроса в файл не вносили своих коррективов в форматирование выгружаемых данных.

Дополнение насчет краев: края хорошо поясняются наличием типов данных CHAR и VARCHAR.

Посвящается всем тем, кто свято верит в то, что у строк и "полей" в T-SQL нет краев, что строки в T-SQL нельзя прижать к краям "поля", что все клиенты "тримят" пробелы.

1. "Столбцы -- в экселе. В MSSQL – поля".
Правило 1 Кодда: Вся информация в реляционной базе данных на логическом уровне должна быть явно представлена единственным способом: значениями в таблицах. Т.е. в MSSQL данные представлены в таблицах. Эксел тоже оперирует таблицами. Таблица, грубо говоря, – это строки и столбцы. Так в чем разница? В том, что, в одном случае, столбец называют полем, а другом случае, называют столбец столбцом? Действительно ли, что у столбца есть края, а у поля их нет?

2.Проведем эксперимент с краями текстового "поля".
Поскольку SQL Server это вещь в себе, будем общаться с ним на "настоящем" клиенте (я бы сказал самым настоящим из всех настоящих клиентов) SQL Server Management Studio (SSMS). Для эксперимента воспользуется запросом:


Задавая разные строки в этом запросе получим:


Как видим, что CHAR не сохраняет справа пробелы исходной строки, а заполняет ими все отведенное для него пространство ("поле"), а VARCHAR сохраняет справа столько пробелов, сколько их есть в исходной строке.
Ни один из этих типов не удаляет и не добавляет пробелы слева в исходную строку.
Пятый пример демонстрирует прижатие строки 'ab' к правому краю "поля" (выравнивание справа).

Т.е. все происходит ожидаемо.

3.Следующий эксперимент. Данные из примера 4 (в строке есть пробелы слева и справа) выгрузим в файлы txt и csv.
Файл csv, если открыть его, например, Блокнотом, будет таким:
" ab ";" ab ";" ab ";" ab ",
а файл txt будет таким:
ab ab ab ab

Т.е. SQL Server, SSMS, файловая система Windows и Блокнот, взаимодействуя друг с другом, не изменили ни количество пробелов, ни их расположение в исходных данных.
Если SQL Server – это сервер, то SSMS, файловая система Windows и Блокнот – это типичные клиенты. Следовательно, не все клиенты "тримят" пробелы.
Комбинация клавиш Ctrl-C, Ctrl-V в SSMS не изменяет количество пробелов и их расположение. А эта же комбинация клавиш в Блокноте удаляет пробелы справа, т.е. выполняет операцию rtrim, но все остальные пробелы остаются на своих местах.

Можно для полноты счастья заархивировать эти файлы и послать по почте; получить их и разархивировать, потом распечатать, и убедиться, что все пробелы остались на своих местах. А ведь это тоже "клиенты".

Вывод, решая задачу нужно знать и использовать возможности имеющихся инструментальных средств. А можно сделать испуганные глаза и сказать, что все равно клиент (тот еще сферический конь в пальто) съест с таким трудом сформированные пробелы.



На этом у меня всё по этой теме. Всем удачи!