|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Добрый день господа. Часто читаю данный форум, но пишу впервые, поскольку не могу осилить. Входные данные: Firebird 2.1, продажная база данных. Имеется рабочая БД, откуда, через IBX выполняю следующий запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
На выходе экспортирую полученные данные из IBX и получаю .txt следующего вида: 4 613 Сидоров Андрей Анатольевич 04.03.2020 10:14:27 1593579 12.000 7 845 Иванов Иван Иванович 04.03.2020 10:14:02 1953722 14.000 Вполне красиво, кроме 000 вместо 00 Далее сделал батник, который надо запускать по расписанию. Через isql выполняю запрос: таким .bat'ником Код: plaintext 1. 2. 3. 4.
выполняю следующий запрос: Код: sql 1. 2. 3.
и получаю следующее: изображение 123. В самой БД, например поле NAME имеет VARCHAR100, т.е. строки фиксированной длины, урезать который я пробовал. Мои попытки применить трим в select не увенчались успехом. Вопрос, как из результата выполнения батника убрать лишние пробелы и лишние нули? Триммировать всю БД не хотелось бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 13:50 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
slj, для числовых - cast, например, если есть numeric(18,3), ему можно сделать cast(field as numeric(18,2)), но в этом случае будет специфическое округление, насколько я помню. А для строковых - встроенная функция TRIM, она есть с ФБ 2.0. https://firebirdsql.org/refdocs/langrefupd20-trim.html ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 13:59 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
kdv, вот у меня trim не выходит вовсе. или я дурак или... Код: sql 1. 2. 3. 4. 5. 6.
cast еще не пробовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 14:52 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Код: sql 1. 2.
Примитивно, но громоздко. Рассмотрите, всё-таки, вариант "форматировать у клиента". ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 15:01 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
slj kdv, вот у меня trim не выходит вовсе. или я дурак или... Код: sql 1. 2. 3. 4. 5. 6.
cast еще не пробовал. Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 15:01 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
slj, эээ... неплохо бы в sql втыкать переводы строки по ширине экрана. А то елозить внизу скроллбаром раздражает. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 15:04 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
kdv slj, эээ... неплохо бы в sql втыкать переводы строки по ширине экрана. А то елозить внизу скроллбаром раздражает. исправлюсь, недоглядел) pastor, спасибо огромное. пару полей убрал, но всё равно результат не полный. Что еще надо убрать? Код: sql 1. 2. 3. 4. 5. 6.
Результат запроса: ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 15:43 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
slj pastor, спасибо огромное. пару полей убрал, но всё равно результат не полный. Что еще надо убрать? а ничего. можно еще у isql настроить ширину вывода. мы себе давно сделали zls_sql, который выводит без разделителей страниц, а при желании в csv или xml ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2020, 15:53 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Если бы была озвучена исходная задача то можно было бы что-то посоветовать. Пока что мне нифига непонятно, для чего выгружать именно в txt. Скорее всего удобнее экспортировать в какой-нибудь xls при помощи IBEScript. Так же есть подозрение что то что в первом сообщении называется IBX, на самом деле имеется ввиду IBE. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 04:45 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Мне кажется что на счет trim() тут советуют фигню. На выходе isql "лишние" пробелы не потому что они в значении поля, а потому что вывод isql пытается изобразить таблицу в текстовом виде, в формате фиксированная ширина полей. Поля varchar() конечные пробелы вообще не умеют хранить, соответственно и тримировать их не нужно. Рекомендация собаковода по форматированию запроса: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
В select лучше видно какие же поля возвращает запрос. В from не опускать INNER с целью подровнять участвующие в запросе таблицы в одну колонку. В where каждое условие начинать с and (если оно конечно and) - тогда при отладке можно легко комментированием отключать условия поштучно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 04:59 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
В IBExpert/IBEScript запрос с экспортом выглядит например так: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 05:18 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks Так же есть подозрение что то что в первом сообщении называется IBX, на самом деле имеется ввиду IBE. :) Ибо если мы запрос получаем через IBX в Delphi, то отформатировать текстовый вывод можно совершенно без проблем и как угодно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 06:06 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks, Накидал кучу нравоучений и спорных указаний по самому правильному форматированию кода, притянул IBEScript, а на вопрос автора ответа не предоставил. Скрипт, конечно, для экспорта хорош, но во многих случаях вполне достаточно isql. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:13 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks, никогда не делай LEFT JOIN до INNER JOIN ибо оптимизатор начинает тупить ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:22 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Симонов Денис, Это не он, а автор. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:28 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Симонов Денис fraks, никогда не делай LEFT JOIN до INNER JOIN ибо оптимизатор начинает тупить Я и не делаю. И вообще, максимально избегаю INNER. Даже и не специально, просто так по задаче получается обычно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 10:10 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks максимально избегаю INNER ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 10:13 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
WildSery fraks, Накидал кучу нравоучений и спорных указаний по самому правильному форматированию кода, Э... в каком месте я сказал что это самое правильное форматирование? Это была моя рекомендация, и ниже я написал свои обоснования для каждого места, почему я считаю что так лучше. WildSery притянул IBEScript, а на вопрос автора ответа не предоставил. Скрипт, конечно, для экспорта хорош, но во многих случаях вполне достаточно isql. А я так и не понял в чем собственно состоит вопрос, и эту свою непонятку и озвучил. Ибо когда ты получаешь на выходе текстовый файл с форматированием полей таблицы пробелами - то тут никаких "лишних" пробелов нет. Если же получать данные в csv - то там выравнивания не будет, и так же, никаких лишних пробелов не будет, ибо varchar(со слов топикстартера, ибо DDL таблицы он не привел). На сколько я вижу - автор нашел какой-то метод вывода данных, первый попавшийся, и пытается на основе него что-то сделать. Можно сколько угодно выдавать рекомендации, но без знания собственно задачи - а для чего и как потом применяются полученные данные, шансы подсказать правильное решение - не очень велики. Но просто потрындеть можно. По поводу isql. При наличии IBExpert и IBEScript - этот isql нафиг не нужен. IMHO у него только одно преимущество - он идет в комплекте. Их чего проистекает 2 момента - его не нужно где-то искать, устанавливать. И это стандартный инструмент для тестирования глючит ли сервер. Для экспорта данных он не пригоден. Автор может конечно покопать в сторону set width или пытаться сформировать строку csv прямо в запросе. Но потом будет следующий вопрос - а как убрать недопустимые для csv символы, как как корректно закавычить строковое поле, и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 10:34 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
У полей varchar() не бывает концевых пробелов, соответственно трим тут не поможет никак. При конкатенации, тип данных результата получается слодением размерности каждого аргумента. Триммируй его или нет, в примере ниже - результат будет varchar(203). Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
isql будет расчитывать ширину колонки именно под этот большой суммарный тип. Потому там столько пустого места. И трим там не поможет. И cast не поможет, потому как или будут "лишние" пробелы либо исключение "string truncation". Используйте для вывода данных инструменты для этого предназначенные. isql - не из их числа, он пригоден только для посмотреть и вывести данные в формате "для АЦПУ". ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:09 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
WildSery fraks максимально избегаю INNER Из моей практики INNER нужен в 1-3% запросах. В остальных чисто по логике используется LEFT. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:10 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks, какая-то странная у вас статистика. Я бы сказал наоборот 30% LEFT, остальное обычный JOIN. INNER здесь слово чисто опционально, в LEFT можно тоже использовать OUTER ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:16 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks Но просто потрындеть можно. fraks Из моей практики INNER нужен в 1-3% запросах. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:36 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Симонов Денис fraks, какая-то странная у вас статистика. Я бы сказал наоборот 30% LEFT, остальное обычный JOIN. INNER здесь слово чисто опционально, в LEFT можно тоже использовать OUTER Я вот даже навскидку не могу припомнить где мне в последний раз был нужен именно INNER. outer + where not null дает тот же результат что и inner, зато мне чисто для мозгов понятнее смысл работы outer. И с оптимизатором меньше рисков что он задурит. Если правильно помню, inner применял только в тех случаях когда с ним получался более оптимальный план, который не получалось получить через outer. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:43 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
fraks И с оптимизатором меньше рисков что он задурит. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:45 |
|
Убрать отступы в select
|
|||
---|---|---|---|
#18+
Ivan_Pisarevsky fraks И с оптимизатором меньше рисков что он задурит. Вы так говорите как будто это что-то плохое :) При написании запроса я практически всегда четко представляю что в каком порядке нужно джойнить что бы с производительностью не получился УПС... И даже с left бывает нужно делать "+0", иногда. А вот с внезапно изменившимся планом приходилось бороться неоднократно, видимо поэтому и завязал с INNER без особой нужды. База наполнена данными, порядок и соотношения количества записей по таблицам мне понятно. И процентное соотношение нужных мне значений в нужных мне полях с малым количеством значений, но с индексом - тоже мне известно и для чего я так задумал. Отдай это на волю оптимизатору - и он рано или поздно неприятно удивит. Стабильность - наше всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:56 |
|
|
start [/forum/topic.php?fid=40&startmsg=39934129&tid=1560411]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
132ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 239ms |
0 / 0 |