Осталось синус довести до 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, но все остальные пробелы остаются на своих местах.

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

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



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

Владислав Колосов,

Что еще сказать?

Я привел условия применения форматирования данных в запросе, массу клиентов для которых это возможно, реальные ситуации, а вы все о элементах управления. Мир не вращается вокруг элементов управления. И зачем использовать элементы управления, которые нельзя настроить на нужное поведение?

Извините, но я уже потерял интерес к этой теме.

"При профессиональной разработке так не поступают". Владислав Колосов.

Я рассказал один эпизод из жизни и закончил его на оптимистичной нотке, не рассказав его настоящий конец. Исправляюсь:

- Так делать нельзя! Это противоречит приказу №ХХХ! – сказал подчиненный.
- А кто готовил этот приказ? – спросил недавно назначенный начальник.
- Мы!
- Так измените этот приказ!
- Мы не можем!
- А что вы можете?
- Отменить этот приказ и издать новый!
- Так сделайте это!
- Так это же… надо внести изменения в текст… распечатать… согласовать… подписать… - начал вслух рассуждать подчиненный.
- Хорошо, пусть всё останется как есть. – упавшим голосом сказал начальник и посмотрел на меня.
Я понял, что должен войти в его положение и утвердительно кивнул головой.

С тех пор прошло более десятка лет, сменилось несколько начальников, продолжает действовать все тот же приказ №ХХХ.

" мир человеков не оскудевает всякими извратами ". Кесарь.

Расскажу еще одну историю из своей жизни.

В начале 90-х нам предложили решить задачу управления несколькими десятками однотипных Устройств, каждое из которых должно выполнять свою задачу независимо от остальных. Для этого выделяется ПК, с помощью которого Оператор будет командовать этими Устройствами. ПК соединяется через свой COM-порт с Контроллером, который должен преобразовывать команды в циклограммы: последовательности импульсов, которым повинуются Устройства. Все хорошо, все работает, все довольны.

Через несколько лет, когда начали разрабатывать третью версию системы, приходит коллега и говорит: стоимость Контроллера составляет существенную часть стоимости всей системы, дороговато, сможешь ли ты сформировать эти циклограммы на выходе LPT порта, если выходов и входов на нем хватает? Остальное он берет на себя.

Теперь уже я начал бекать: могу, но ОС не система реального времени, микросекунды можно обеспечить только глупым счетом, гарантируется минимальная длительность импульсов (пауз), максимальная длительность импульсов будет непредсказуемой, да и не царское это дело, есть же для этого Контроллер. Он и должен разворачивать команды в циклограммы. К тому же деньги за новую версию Контроллера уже заплачены. А изменение длительности импульсов в большую сторону критично? Нет, главное, чтобы мы успели за заданное время обслужить все Устройства и не забыть об Операторе, который в самый неподходящий момент захочет покомандовать Устройствами или получить отчет. Попробуем? Я нехотя согласился, будучи уверенным в провале этого дела. Тем более, что в этой версии мы наконец-то решились окончательно перейти от файлов к БД и не всё шло гладко.

Сколько шуток мы породили на тему, что все нормальные (наверно, это синоним слова профессиональные) программисты отлаживают свои программы в отладчике, а эти ненормальные в осциллографе. В итоге, вместо придаваемого к ПК ящика-посредника, появилась одна плата ключей, которая размещалась в корпусе ПК и запитывалась от его же блока питания. Появились две процедуры Out(контакт, значение); Delay(t :время в мкс, k :коэффициент), которая просто считала от 0 до k*t, где k – подбирался (ужас какой!) под конкретный тип ПК и хранился в файле настроек; и одна функция In(контакт, значение). Переписали модуль формирования команд с помощью этих трех примитивов без изменения его интерфейса. Поэтому вся остальная часть ПО не узнала об этом непрофессиональном изменении одной из ее частичек. Я почувствовал себя Властелином этих жалких Устройств! Мне уже не надо вежливо просить Контроллер распорядиться, чтобы вот то Устройство сделало вот это!

Через некоторое время после поставки новой системы, которую мы гордо назвали системой третьего поколения, появилась серьезная проблема: Эксперты Заказчика сказали, что стоимость системы завышена. Посчитали стоимость ПК + стоимость радиодеталей и пришли к выводу, что купили один ПК по цене трех. Эти же Эксперты пообещали Заказчику сделать такое-же за пару недель и дешевле. С учетом этих факторов дальнейшее сотрудничество в этой области с нами прекращается. Дело хозяйское, у нас нет ни одной возможности вставить вам палки в колеса… Вот он, реальный результат непрофессиональных технических решений! А ведь внутренности Контроллера магически влияли на стоимость системы в сторону увеличения! Как объяснить всем о нашем провале?.. Через примерно полгодика мы получили заказ на очередную систему.

С течением времени все меняется: ПК становились 386, 486, …, ОС – DOS, Windows 95. Появилась 2000-я и прямой доступ к портам был перекрыт. Осилили собственный драйвер LPT. Появились сети компьютеров и SQL, стал исчезать LPT. Наше ПО тоже не стояло на месте, но способ формирования импульсов не менялся, увеличивался только коэффициент k. А плату ключей мог отремонтировать любой, кто умеет держать в руке паяльник.

Система прожила более четверти века и сейчас потихоньку заменяется новой, системой четвертого поколения, со стандартным сетевым протоколом. Снова появился ящик-посредник, теперь он называется Коммутатором. И я уже не Властелин этих Устройств, которые стали умнее меня. Теперь я вежливо прошу их сделать вот это. Все развивается по спирали.
Многие отчеты в этой системе формируются примерно так: 20189198 , 17632966 , выводятся в компонент TMemo как обычный текст, который либо отображается на экране, либо сразу печатается без показа на экране. Читая такие вопросы, у меня крепнет чувство, что я не одинок во Вселенной.

Вывод, который я тогда сделал: МОЖНО И НУЖНО ИСПОЛЬЗОВАТЬ ЛЮБЫЕ УЖЕ ИМЕЮЩИЕСЯ ВОЗМОЖНОСТИ И НЕ БОЯТЬСЯ РАЗГОВОРОВ О НЕПРОФЕССИОНАЛИЗМЕ И ИЗВРАТАХ. Позже я узнал, что это частный случай бритвы Оккама: "Не следует множить сущее без необходимости". Принцип, известный философам Древней Греции. Следую ли я этому? Не всегда.

Кесарь,

1.Эта идея была не моей, я был её противником, но только на первом этапе, пока не понял ее перспективы. Это позволило уменьшить затраты на производство системы, а цена продажи не изменилась. И Заказчик, как я сказал, через некоторое время заказал очередную систему. Главное, не бояться посмотреть на ситуацию другими глазами.

2. Спасибо за советы по маркетингу. Поделюсь своим взглядом на маркетинг, брендинг, ребрендинг и прочую современность. К нам часто приходят мальчики и девочки, рассказывающие красивые сказки, как что-то у нас вырастет, если мы примем их стратегию.

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

- нужно решать проблему Заказчика и говорить с ним на его языке, а не рассказывать ему, например, о виртуальном поглощении пробелов визуальными элементами управления.

-разумная лицензионная политика. Мы отказались от нее совсем. Экземпляр ПО передается в собственность Заказчика, количество Устройств он может увеличивать, без изменения программы. Часто звонят и просят прислать "лицензии" на наше ПО, которое требуют какие-то органы, мы отвечаем: читайте договор, там написано, что этот экземпляр ПО ваш и вы можете делать с ним всё, что хотите. Это вызывает шок у бухгалтеров и проверяющих, воспитанных на лицензиях их бухгалтерского ПО.

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

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

- повторюсь, максимально возможное использование имеющихся технических средств. Например, функции контроллера, которые выполнялись его микропроцессором со всем антуражем вокруг этого микропроцессора, были перенесены в ПО, а тот кабель, который связывал Контроллер с Устройствами, теперь подключается к плате ключей. Ключи необходимы, потому что мощность сигналов на выходе LPT недостаточна, и это все, что осталось от hardware Контроллера. При этом даже не пришлось переделывать разъем этого кабеля. На плате ключей было достаточно установить нужную ответную часть разъема.

- не складывайте яйца в одну корзину. Никогда точно не узнаешь, почему одна система взлетела, а другая, более совершенная, была отвергнута.

Владислав Колосов,

" ... накладывает ограничение на ... "
В мире на всё накладываются ограничения. Я не видел универсальную лампочку, которая одинаково хорошо подходила бы как к освещению большой комнаты, так и к освещению внутренности холодильника. На мерседесе, даже 600-м, никто не возит бетонные блоки, а на Камазе никто в городе не ездит на работу. Чтобы вывести на заданную орбиту спутник нужна определенная скорость, не ниже и не выше. Зачем придумали столько типов данных, если можно использовать один универсальный? Уже выросло поколение программистов, которым типизация мешает создавать их великие творения. Стандартная ситуация: база данных – запрос – текстовый файл – принтер – бумага. Цепочка отработана, визуализация происходит на бумаге. Что в этой цепочке является "только_специальный_клиент"? Бумага? Да, для каждого типа принтера нужна бумага с определенными характеристиками. Если принтер не может печатать на ватмане, то его место на свалке?

Связность, зависимость . Всё в нашем подлунном мире взаимосвязано и взаимозависимо. Несвязность и независимость существует только в пустых головах молодежи, которая бегает по майданам и площадям с криками и плакатами.

" Если бы связность системы была низкой, то достаточно было бы заменить COM на USB без изменения даже разводки основных плат ".

Сюжет из жизни. Сидим, как-то вечером на работе, обсуждаем создание "специального клиента". Комнату убирает наша уборщица. Метет веником и говорит нам: "Не пора ли идти по домам, а то я вас сейчас обмету веником, и вы не женитесь!". Мой коллега молниеносно ответил: "Эх! Где же вы были 20 лет назад!?".