Получите полный список уникальных значений из нескольких столбцов в нескольких таблицах

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

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

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

TL;DR: Как проще всего получить столбец уникальных значений нескольких столбцов, разбросанных по нескольким таблицам?

Заранее спасибо за помощь!


person Matt Parker    schedule 25.08.2010    source источник
comment
Каков ваш реальный вопрос? Вы говорите, что объединяете две таблицы в ОБЪЕДИНЕНИЕ, но спрашиваете, каково ограничение на количество операторов SELECT в ОБЪЕДИНЕНИИ? Или что-то еще? То есть ответ, который вам дали, очевидно, вы уже обдумывали, но почему-то колеблетесь над ним. Мне интересно, каков ваш настоящий вопрос.   -  person David-W-Fenton    schedule 26.08.2010
comment
По сути, я предвидел те же трудности, что и при объединении нескольких таблиц в SQL. Я понятия не имел, что их можно просто складывать. У меня очень редко есть причины рисковать, кроме объединения двух таблиц, поэтому, когда я это делаю, мне трудно разобраться с собственными заблуждениями и кучей довольно плохих советов по SQL в Интернете.   -  person Matt Parker    schedule 26.08.2010
comment
Мне кажется, у вас терминологические проблемы. ОБЪЕДИНЕНИЕ не является СОЕДИНЕНИЕМ — СОЕДИНЕНИЕ — это когда вы ВЫБИРАЕТЕ поля из нескольких связанных таблиц в одну строку. UNION берет результаты нескольких независимых SELECT и объединяет их в один набор данных. Обычно, когда люди говорят о сложенных запросах, они имеют в виду вложенные запросы, тогда как вы, кажется, используете это для того, что такое UNION. Возможно, это часть источника путаницы, что вы просто изучаете термины, которые большинство людей используют для этих понятий.   -  person David-W-Fenton    schedule 27.08.2010
comment
Я бы сказал, что это даже не терминологическая или концептуальная проблема, а скорее необоснованное предположение о том, что если выполнять 3+ соединения таблиц — это боль в заднице (что на самом деле не так, я только что столкнулся с этим ранее), то это также должно быть больно делать союзы. Очевидно, что это не так. Но да, в целом: новичок борется.   -  person Matt Parker    schedule 27.08.2010


Ответы (1)


Объедините запросы SELECT для каждой из таблиц в запрос UNION. Запрос UNION возвращает различные значения.

SELECT UserID FROM Table1
UNION
SELECT UserID FROM Table2
UNION
SELECT UserID FROM Table3;
person HansUp    schedule 25.08.2010
comment
Э, ну... Я немного смущен тем, как легко это было. Спасибо! - person Matt Parker; 26.08.2010