Нужна помощь в присоединении к столу

У меня есть функция, которая экспортирует таблицу в CSV, и в запросе я задаю, какие поля будут экспортироваться.

Вот запрос:

SELECT lname, fname, email, address1, address2, city, 
state, zip, venue_id, dtelephone, etelephone, tshirt FROM volunteers_2009

Поле «место проведения_ид» — это идентификатор места, на которое ссылаются в другой таблице (местах).

Таким образом, волонтеры_2009.venue_id = места проведения.id

Когда я открываю CSV-файл, он отображает место проведения_id, которое я понимаю, но мне нужна помощь в изменении запроса, чтобы указать название места проведения (venues.venue_name) в CSV-файле.

Любая помощь приветствуется.


person Brad    schedule 25.11.2008    source источник


Ответы (3)


Стандартный SQL-запрос для этого (при условии, что вам нужны и идентификатор, и название места проведения):

SELECT a.lname as lname, a.fname as fname, a.email as email,
    a.address1 as address1, a.address2 as address2, a.city as city, 
    a.state as state, a.zip as zip, a.venue_id as venue_id,
    b.venue_name as venue_name, a.dtelephone as dtelephone,
    a.etelephone as etelephone, a.tshirt as tshirt
FROM volunteers_2009 a, venues b
WHERE a.venue_id = b.id
AND a.venue_id IS NOT NULL
UNION ALL
SELECT a.lname as lname, a.fname as fname, a.email as email,
    a.address1 as address1, a.address2 as address2, a.city as city, 
    a.state as state, a.zip as zip, a.venue_id as venue_id,
    '' as venue_name, a.dtelephone as dtelephone,
    a.etelephone as etelephone, a.tshirt as tshirt
FROM volunteers_2009 a
WHERE a.venue_id IS NULL
person paxdiablo    schedule 25.11.2008
comment
Работает хорошо, за исключением того, что он не экспортирует записи, для которых в этом поле нет места проведения_id. - person Brad; 25.11.2008
comment
Вы говорите, что они могут быть NULL в волонтерах_2009; или вы говорите, что они могут быть установлены на значение, которое не существует в местах проведения? - person paxdiablo; 25.11.2008
comment
Избегайте синтаксиса FROM A, B. Вместо этого используйте FROM A INNER JOIN B. - person Joel Coehoorn; 25.11.2008
comment
Оно помечается как NULL, если в этом поле не хранится идентификатор места проведения. - person Brad; 25.11.2008
comment
@Brad: используйте внешнее соединение, это полностью зависит от требований - person Nrj; 25.11.2008
comment
@ Джоэл, почему ты предпочитаешь внутреннее соединение? Ни в одной БД, которую я использую, нет разницы в производительности. - person paxdiablo; 25.11.2008
comment
Это не представление. Это ясность и переносимость, особенно когда вы начинаете работать с более чем двумя или тремя таблицами в одном запросе. - person Joel Coehoorn; 25.11.2008
comment
Ах я вижу. Я предполагаю, что это потому, что мы из разных слоев общества. У мэйнфреймов есть множество администраторов баз данных, которые решают эти проблемы, а производительность всегда оценивается выше удобочитаемости (поэтому те же самые администраторы баз данных сохраняют свои рабочие места). :-) - person paxdiablo; 25.11.2008

SELECT lname, fname, email, address1, address2, city,   
state, zip, b.venue_name, dtelephone, etelephone, tshirt FROM   
volunteers_2009 a, venues b  
where a.venue_id = b. venue_id

используйте правильный псевдоним, если обе таблицы имеют столбцы с одинаковыми именами.

--- ИЗМЕНИТЬ, чтобы все строки из мест проведения использовали внешнее соединение как

SELECT lname, fname, email, address1, address2, city,   
state, zip, b.venue_name, dtelephone, etelephone, tshirt FROM  
volunteers_2009 a(+), venues b  
where a.venue_id = b. venue_id
person Nrj    schedule 25.11.2008

person    schedule
comment
@Joel, это влияет на производительность, поскольку вы выполняете поиск в таблице и вызов функции для каждой записи. Двухпроходный подход (объединение всех) выполняет поиск в таблице только для ненулевых идентификаторов мест проведения, и даже не для нулевых (и без вызовов функций). - person paxdiablo; 25.11.2008
comment
Хотя производительность, вероятно, не будет иметь большого значения, поскольку вы все равно используете MySQL :-). - person paxdiablo; 25.11.2008
comment
На самом деле, я уточню это последнее утверждение - я не имел в виду, что MySQL была игрушечной БД (это так, по сравнению с DB2/z, но это другой вопрос), просто она используется в основном там, где вы не платите за Использование ЦП (в отличие от мейнфрейма DB2). - person paxdiablo; 25.11.2008