CONSTRAINT върху UNION? (MySQL, PostgreSQL)

Имам 3 заявки, които обединявам с UNION.

SELECT id, name FROM ids1
UNION
SELECT id, name FROM ids2
UNION
SELECT id, name FROM ids3

Трябват ми DISTINCT id-тата и извадените им имена (name) с този приоритет на таблиците (приемаме, че комбинацията id-name е различна в трите таблици). По принцип сега го правя като създавам TEMPORARY TABLE и слагам вътре UNIQUE(id) като след това правя INSERT IGNORE и пак гореспоменатия UNION. Въпросът ми е, как е по-добре...да правя 3 пъти INSERT IGNORE без UNION или един INSERT IGNORE с UNION - понеже UNION така или иначе създава временна таблица, но ми е интересно кое е по-бързо?...И каква е алтернативата на всичко това с PostgreSQL?

Everything louder than everything else...

кое е по-бързо ти трябва сам да видиш ;-)

аз предполагам, че варианта с временна таблица и блъскайки в нея с insert ignore ще е най-бързо

вариант за postgresql, който ми се вижда най-читав
пак временна таблица с unique индекс
и правиш

insert into temp_table select * from ids1;
insert into temp_table select * from ids2 where not exists (select 1 from temp_table where temp_table.id = ids2.id);
insert into temp_table select * from ids3 where not exists (select 1 from temp_table where temp_table.id = ids3.id);

Аха...абе нещо ми се струва, че мажа яко с тия безбройни union-и, ама като гледам няма друг начин. Мерси.

Everything louder than everything else...

UNION (за разлика от UNION ALL) по дефиниция праи дистинкт.
Така че резултата на униона ще бъдат всичките уникални комбинации от ид и име от трите таблици.

той веднъж преди време беше питал за нещо подобно и предполагам това му е за същото нещо, на него не му трябва уникални редове, а уникални id-та
причината е, че по няква причина ;-)) има в едната таблица едно id с едно име, а в другата същото id, но с друго име
так union връща и двете, а на него не му трябва това

Не точно за същото, но пак е свързано. В предния случай станаха 300 реда заявки една след друга.

А реално нещата са доста по-сложни, правя изкарване на users от много различни места = много асоциации, като в добавка, всеки user може да бъде вързан към всеки обект с различна роля. И именно тези роли ми правят мръсното...

Everything louder than everything else...

В PostgreSQL можех да напишеш следното:
select distinct on (id) id, name from table

Имай пред вид че е свързано с order by клаузата

И какво точно ще съдържа колонката name при този синтаксис?

Много силно ми напомня на MySQL синтаксиса

SELECT id, name FROM table GROUP BY id;

за който привърженици на PostgreSQL твърдят, че докато MySQL го поддържа изобщо не може да бъде наречена "правилна" СУБД

salle.online.bg/sig

ако се ползва ORDER BY ще е предсказуемо, ако не се ползва, няма да е предсказуемо ;-))

[линк]

а този вариант също е възможен в случая, но не съм сигурен дали ще е ефективен (имам предвид, за проблема на Дакота ;-))

Обикновено избягвам да се заяждам, но в случая става въпрос за нестандартна възможност. А ми е омръзнало да чета как MySQL e пълен боклук защото има такива нестандартни разширения за разлика от правоверните които поддържат точно и както трябва стандарта....

А SQL 99 определено забранява DISTINCT ON
В същото време позволява
SELECT id, MIN(name) ...или MAX ... FROM table GROUP BY id;

Нали така?
Т.е. в случая PostgreSQL предлага алтернативен нестандартен синтаксис за нещо което е изпълнимо със стандартнен синтаксис.

Нещо, което лично на мен никога не ми е пречело, но определено страшно много хора използват за да тръбят как MySQL за нищо не става само защото предлага подобни алтернативни варианти.

salle.online.bg/sig

амиии начи ..... няма база, която да няма собствени разширения на синтаксиса, явно е норманло ;-)

но postgresql е най-малко бягащото от стандарта, обаче що се отнася до SQL т.е. без stored процедури, там (в stored процедурите) има доста разширения/различия (изобщо много езици, които нямат нищо общо с SQL, като python, perl, дори и php)

а това, което в случая се постига с този синтаксис, може да се постигне и по друг начин (в случая май с HAVING ще стане, но доста по-бавно решение), но то за почти всички разширения е така ;-)

а както също казах на дакота, точно това май няма да свърши работа