LINUX.ORG.RU

SQL запрос для выборки из двух таблиц с одинаковыми полями

 ,


0

1

Есть две таблицы в SQLite3:

CREATE TABLE user_real_connect (
login TEXT NOT NULL,
name TEXT NOT NULL
);

CREATE TABLE user_tiket_connect (
login TEXT NOT NULL,
name TEXT NOT NULL
);
Я понимаю, что такие таблицы не нормированы. Но уж что есть то, есть.

Задача: просто получить одним запросом логины из обоих таблиц. То есть, как бы присоединить одну таблицу снизу к другой.

Если перечислить в секции FROM таблицы через запятую, то будет ошибка:
select login from user_real_connect, user_tiket_connect;
Error: ambiguous column name: login
А если в секции FROM писать одну таблицу, то ошибки нет.

Каким должен быть запрос, чтобы вывести значение поля login из двух таблиц?

★★★★★

Последнее исправление: Xintrea (всего исправлений: 1)

Ответ на: комментарий от anonymous

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



Не то. С UNION всеравно надо писать по отдельному запросу на каждую таблицу, а потом их объединять. А нужен один запрос на две таблицы.

Xintrea ★★★★★
() автор топика

Error: ambiguous column name: login

Неужто SQLite3 не поддерживает имена таблиц в названии поля

anonymous
()
Ответ на: комментарий от Xintrea

нужен один запрос на две таблицы

откуда такое требование? просто так захотелось?

anonymous
()
select login from user_real_connect
union
select login from user_ticket_connect;
theNamelessOne ★★★★★
()
Ответ на: комментарий от Xintrea

по отдельному запросу на каждую таблицу, а потом их объединять

Так говоришь, как будто ты это руками делаешь. С такой аргументацией можно до чего угодно докопаться: «Подзапрос - это сначала сделать один запрос, а потом его результат использовать в другом запросе, а хотелось бы, чтобы был один запрос.»

winlook38 ★★
()
Ответ на: комментарий от Xintrea

А какой должен быть запрос?

select urc.login, utc.login from user_real_connect as urc, user_tiket_connect as utc;

Но это не то, что тебе нужно (по крайней мере если тебе действительно не нужно декартово произведение записей из двух таблиц).

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от winlook38

да этот товарищ вообще неадекват какой-то, у него многие топики подобным бредом пахнут

anonymous
()
Ответ на: комментарий от anonymous

Неадекваты это те, кто вместо

veryLongVariableName+=const;

пишут
veryLongVariableName=veryLongVariableName+const;

И тут вдруг находятся люди, которые утверждают, что
select login, name, cdata, id from user_real_connect
union
select login, name, cdata, id from user_ticket_connect;
- это норма. А вот такое:
select login, name, cdata, id from user_real_connect BOTTOMJOIN user_ticket_connect;
- это ужас-ужас.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

И тут вдруг находятся люди, которые утверждают, что […] - это норма. А вот такое: […] - это ужас-ужас.

Осталось реализовать оператор BOTTOMJOIN, и будет тебе успех!

theNamelessOne ★★★★★
()
Ответ на: комментарий от Xintrea

это

veryLongVariableName=veryLongVariableName+const;
и это
select login, name, cdata, id from user_real_connect
union
select login, name, cdata, id from user_ticket_connect;
хоть работают
а это
select login, name, cdata, id from user_real_connect BOTTOMJOIN user_ticket_connect;
что вообще за хрень такая? ты на ходу изобретаешь новые ключевые слова SQL'я и желаешь, чтобы они работали так, как ты задумал уже в текущей версии базы?

смишной чюдик :)

anonymous
()
Ответ на: комментарий от theNamelessOne

Я думаю, он рано или поздно будет реализован. В SQL очень многих естественных вещей до поры до времени небыло, например вариации ALTER TABLE. И только лоровцам приходит в голову заявлять о том, что то что не реализовано - ненужно.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

то почему нет?

То почему да? Зачем делать функционально более ограниченный аналог UNION?

theNamelessOne ★★★★★
()
Ответ на: комментарий от Xintrea

Если не противоречит теории реляционных таблиц

Какая семантика в реляционной алгебре у оператора BOTTOMJOIN и чем она отличается от оператора UNION?

theNamelessOne ★★★★★
()
Ответ на: комментарий от Xintrea

эта твоя придуманная хрень вообще не естественна.
потому что во-первых сам union используется не так часто, а чтобы еще попался кейс, когда тебе
1) надо выбрать записи из 2 таблиц
2) по столбцам с одинаковыми названиями
3) с одинаковыми типами
4) и объединить их
будет встречаться совсем редко (если не так, то у тебя какие-то проблемы на проекте). и придумывать для этого новый оператор - это полный бред.

Deleted
()
Ответ на: комментарий от Deleted

Ну вот я только копнул SQL, и сразу вижу одинаковые таблицы типа order_2013, order_2014, order_2015, order_2016. Структура одна. И нужны отчеты за все года скопом. И не только по двум таблицам, а по трем-пяти.

Понятно, что можно извратиться через UNION, но придется помучиться. А если выборку делать по другим полям, то пять раз перепроверять поля в каждом селекте.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

И нужны отчеты за все года скопом

и как часто тебе нужны эти отчеты? каждый раз заново писать будешь? или все таки тебе нужно написать один раз запрос, сохранить и забыть?

в крайнем случае

create view moya_mama_ababzhur as
select <все твои колоночки>,'order_2013' as tab_name from order_2013
union all
select <все твои колоночки>,'order_2014' as tab_name from order_2014
union all
select <все твои колоночки>,'order_2015' as tab_name from order_2015;

и работаешь дальше с вьюхой. и не тупишь.

Deleted
()
Ответ на: комментарий от Xintrea

вижу одинаковые таблицы типа order_2013, order_2014, order_2015, order_2016. Структура одна. И нужны отчеты за все года скопом.

Ты предлагаешь новый оператор для одной конкретной ситуации, которую к тому же уже решили партифицированием (да, не все СУБД поддерживают этот механизм).

winlook38 ★★
()
Ответ на: комментарий от theNamelessOne

да в случае с большинством СУБД может. кстати, я не знал, что в постгрес партицирование так странно сделано, спасибо за ссыль :)

Deleted
()
Ответ на: комментарий от Deleted

Ну даже если часто нужны - можно ведь так сделать:

SELECT group_concat(sql, char(10) || 'union all' || char(10))
FROM (SELECT 'select login, name, cdata, id from ' || name AS sql
      FROM sqlite_master
      WHERE name LIKE 'order_%');

Ja-Ja-Hey-Ho ★★★★
()
Ответ на: комментарий от Xintrea

Ну вот я только копнул SQL, и сразу вижу одинаковые таблицы типа order_2013, order_2014, order_2015, order_2016

Почему ты считаешь, что в языке SQL должны быть операторы для облегчения доступа к БД с кривожопым дизайном? Это проблема тех, кто такую БД состряпал. Это проблема тех, кто, к несчастью, с ней работает (здесь могу тебе посочувствовать). Но никак не проблема авторов SQL. Вообще никак.

Тебе прямо сейчас либо UNION (как советовали выше), либо в программе делаешь динамические запросы. Не прямо сейчас - постарайся получить с заказчика дополнительные деньги за вредность. Заодно постарайся внушить ему, что те, кто делал ему БД - неквалифицированные уроды, и её надо переделывать. Если заказчик не понимает ни первого, ни второго, постарайся больше не иметь дела с таким заказчиком.

Но не смей, слышишь,не смей обвинять язык SQL в том, что у тебя криворукий заказчик с кривой структурой БД. Это не проблема SQL.

anonymous
()
Ответ на: комментарий от Xintrea

Понятно, что можно извратиться через UNION

Ещё раз: это не UNION извратный, это база у тебя извратная.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.