Как выполнить оператор SQL UNION?

[Франц]

Доброе время суток всем!

Version: 24.8.2.1 (X86_64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL threaded

Вот такое выражение SQL не работает:

Код Выделить Развернуть

SELECT * FROM "Cat_10"
UNION ALL
SELECT * FROM "Cat_21";

Screenshot 2024-10-29 192631.png

Но в букваре "Base Guide 7.2", например, написано:
UNION [ALL | DISTINCT] Query_result
This links queries so that the content of the second query is written under the first. For this
to work, all fields in both queries must match in type. This linkage of several queries'
functions only in direct SQL command mode.

Вроде бы в командном режиме стартую, или нет?

[Франц]

А! Нажал кнопочку "SQL" на тулбаре дизайнера и после попытки запуска получил уже сообщение "Невозможно выполнить запрос. Он слишком сложен."

[Франц]

В общем, таблицы в БД являются прикрученными листами из документа Calc (в этом наверное причина ошибки). Хотя SELECT по ним работает.
Если же сделать обычную БД и в ней создать две одинаковые таблицы, то UNION выполняется.
Жаль конечно, что такие ограничения функционала.

[economist]

Ограничения в Base c readonly-данными есть, документации по ним мало, многое что написано - работает не так как написано (я про SQL-функции работы с текстом, датами итд).

Есть способ обойти их, и одновременно ускорить выполнение запросов в 4-6 раз. Суть: скриптом на python+pandas создаем один *.ods из нескольких. Используем. Мои примеры скриптов есть на Форуме, повторяться не могу.

Наиболее важным с т. зр. практики тут является то, что в 5-ти строчном скрипте на Python вы можете делать, прямо во время объединения, различные расчеты, конвертации итд. Их скорость - максимальна из возможного, т.к. данные хранятся в RAM.

Если сравнивать "размеры геморроев" с освоением Pandas и обходом ограничений Base - они сопоставимы. Но в случае с Python будет полное исцеление навсегда, а с Base+БДТаблица - лишь временное облегчение симптомов, с частыми рецидивами после. Также можно восхититься новинкой DuckDB. Эта БД доступна в Base, лишь в разы уступает RAM-базам по скорости, но при этом намного быстрее всего остального, и даже SQLite. Предположу что вам очень пригодится ее партиционирование, которое работает ну просто зашибись. По скорости, числу встроенных коннекторов "ко всему" УткаБД чемпион. Тот самый случай, когда можно прекратить поиск, потому что лучшее найдено.   

[sokol92]

Также можно восхититься новинкой DuckDB. Эта БД доступна в Base, лишь в разы уступает RAM-базам по скорости, но при этом намного быстрее всего остального, и даже SQLite.

Добрый день!
А что с tdf#160547 ?

[Франц]

Ограничения в Base c readonly-данными есть, документации по ним мало, многое что написано - работает не так как написано (я про SQL-функции работы с текстом, датами итд).

Есть способ обойти их, и одновременно ускорить выполнение запросов в 4-6 раз. Суть: скриптом на python+pandas создаем один *.ods из нескольких. Используем. Мои примеры скриптов есть на Форуме, повторяться не могу.

Наиболее важным с т. зр. практики тут является то, что в 5-ти строчном скрипте на Python вы можете делать, прямо во время объединения, различные расчеты, конвертации итд. Их скорость - максимальна из возможного, т.к. данные хранятся в RAM.

Если сравнивать "размеры геморроев" с освоением Pandas и обходом ограничений Base - они сопоставимы. Но в случае с Python будет полное исцеление навсегда, а с Base+БДТаблица - лишь временное облегчение симптомов, с частыми рецидивами после. Также можно восхититься новинкой DuckDB. Эта БД доступна в Base, лишь в разы уступает RAM-базам по скорости, но при этом намного быстрее всего остального, и даже SQLite. Предположу что вам очень пригодится ее партиционирование, которое работает ну просто зашибись. По скорости, числу встроенных коннекторов "ко всему" УткаБД чемпион. Тот самый случай, когда можно прекратить поиск, потому что лучшее найдено.   

Благодарю Вас за совет! Приму к сведению.
Скажем так, я не мастер кунг-фу, и хотелось бы обойтись без скриптов и программирования. Хотя и пишут что пайтон - это быстро, легко и непринужденно, но я что-то сомневаюсь что у меня хватит сил освоить.

Вообще, эта тема возникла из моего прошлого опыта работы со связкой Exel + Access (те что MS). В Access к базе очень просто присоединялись листы Excel (если не ошибаюсь, то даже не просто листы, а именованные диапазоны). Масса таких вот присоединенных таблиц легко обрабатывалась встроенным SQL. Результат экспортировался во что надо, красота!

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

Т.е., я склоняюсь больше к обработке табличных данных средствами SQL. И не возражаю против пайтона и т.п., просто для меня сейчас это на другой планете, не долететь.

[kompilainenn]

>Хотя и пишут что пайтон - это быстро, легко и непринужденно,

Брешут