Клубове Дир.бг
powered by diri.bg
търси в Клубове diri.bg Разширено търсене

Вход
Име
Парола

Клубове
Dir.bg
Взаимопомощ
Горещи теми
Компютри и Интернет
Контакти
Култура и изкуство
Мнения
Наука
Политика, Свят
Спорт
Техника
Градове
Религия и мистика
Фен клубове
Хоби, Развлечения
Общества
Я, архивите са живи
Клубове Дирене Регистрация Кой е тук Въпроси Списък Купувам / Продавам 07:33 22.05.24 
Компютри и Интернет
   >> Бази данни
*Кратък преглед

Тема "обратното" на joinнови  
Автор Masklin (ном)
Публикувано04.03.08 18:53



Здравейте.

Представете си две таблици, свързани в съотношение 1:n - в едната има id и някакви данни, а в другата ключ към първата и нейните си данни; във втората няколко реда могат да имат един и същ външен ключ.

Питането е следното: как да вземем тези редове от първата таблица, към които няма ключ във втората?

Сещам се за един начин, но ми се струва неразумен от гледна точка на производителност:

select distinct a.* from a, b where a.id != b.a_fkey 


Предполагам, че решението е очевидно, но не се сещам. Идеи?



Тема Re: "обратното" на joinнови [re: Masklin]  
Автор wqw (АзСъмЖив)
Публикувано04.03.08 19:33



-- old-school за single column keys

select a.*
from a
where a.pk not in (select a_fkey from b)

-- old-scool за composite keys
select a.*
from a
where not exists (select *
from b
where b.a_fkey = a.pk)

-- neo-gamei
select a.*
from a
left join b
on a.pk = b.a_fkey
where b.pk is null

(not tested)




Тема Благодарянови [re: wqw]  
Автор Masklin (ном)
Публикувано05.03.08 13:56





не бях съобразил, че проверката се прави върху данните от декартовото произведение (т.е. резултата от left join-а), а не в самата таблица. Поради което можеш да правиш ... where b.pk is null



Тема Re: Благодарянови [re: Masklin]  
Автор wqw (АзСъмЖив)
Публикувано05.03.08 19:59



Мне е декартовото произведение. Просто по дефиниция OUTER JOIN е INNER JOIN който е UNION ALL с NOT IN така някак:

SELECT a.*, b*
FROM a
JOIN b
ON a.pk = b.a_fkey

UNION ALL

SELECT a.*, NULL, NULL, NULL, ...
FROM a
WHERE a.pk NOT IN (SELECT a_fkey FROM b)

Аз лично ползвам old-school аналозите щото са >= бързи от OUTER JOIN-а (това при MSSQL). Чат-пат db-engine-а не може да съобрази, че няма да дублира редове от a заради JOIN-а. Със sub-select винаги се ориентира че резултатът е подмножество на a (логично като няма нищо друго във FROM клаузата:-)).

cheers,
</wqw>




Тема composite keysнови [re: wqw]  
Автор Dakota (erotoman)
Публикувано07.03.08 15:26



Всъщност и за множество ключове може така:

SELECT

a.*
FROM
a
WHERE
(a.pk1, a.pk2) NOT IN (SELECT a_fkey1, a_fkey2 FROM b);


Но за големи стойности на b, по-добре е другото... в повечето случаи, и пак... прословутото зависи.

Everything louder than everything else...

Редактирано от Dakota на 07.03.08 15:28.



Тема Re: composite keysнови [re: Dakota]  
Автор wqw (АзСъмЖив)
Публикувано11.03.08 17:21



MSSQL и Access не разбират от използване на tuples по този начин. Съвсем забравих, че бази данни = MySQL в този форум :-))

cheers,
</wqw>




Тема Re: composite keysнови [re: wqw]  
Автор phpGuru (непознат )
Публикувано12.03.08 15:13



амии по скоро ти приемаш за база данни за MSSQL или access



Тема Re: composite keysнови [re: wqw]  
Автор Dakota (erotoman)
Публикувано12.03.08 21:13



Е, това го ползвам в PostgreSQL. За MySQL изобщо не знам дали работи.



А иначе балимааму как е по стандарт.

Everything louder than everything else...

Тема Re: "обратното" на join [re: wqw]  
Автор _danitu (аз)
Публикувано19.03.08 14:52



Въпросче: трите варианта по-бързи ли ще са от това например и защо

SELECT a.id, a.a1, a.a2
FROM [а] LEFT JOIN [c] ON a.ID = c.id_a
GROUP BY a.id, a.a1, a.a2
HAVING (((Count(c.id))=0));

Сори на автора, че се възползвам от темата ;)

Редактирано от _danitu на 19.03.08 14:54.



Тема Re: "обратното" на joinнови [re: _danitu]  
Автор Dakota (erotoman)
Публикувано19.03.08 20:46



Е, това е най-лошият вариант дотук. Изпускаш питомното (WHERE), за да гониш дивото (HAVING).



Everything louder than everything else...


*Кратък преглед
Клуб :  


Clubs.dir.bg е форум за дискусии. Dir.bg не носи отговорност за съдържанието и достоверността на публикуваните в дискусиите материали.

Никаква част от съдържанието на тази страница не може да бъде репродуцирана, записвана или предавана под каквато и да е форма или по какъвто и да е повод без писменото съгласие на Dir.bg
За Забележки, коментари и предложения ползвайте формата за Обратна връзка | Мобилна версия | Потребителско споразумение
© 2006-2024 Dir.bg Всички права запазени.