Diskuze: MSSQL - Inner join - Where
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.


Zobrazeno 9 zpráv z 9.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.


Nedávno jsem řešil něco podobného. Ten tvůj druhý dotaz bych udělal spíš takhle
SELECT * FROM faktury f
INNER JOIN uzivatele u ON f.ID_Uzivatele=u.ID AND u.Oddeleni='IT'
WHERE u.Bydliste = 'IT'
Ta druhá podmínka by taky možná šla vložit přímo do JOINU, to už si musíš vyzkoušet sám
Ahoj,
orientace zpracování dotazů funguje v tomto pořadí:
FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY.
V tvém případě bych určitě postupoval takto:
SELECT *
FROM faktury AS f
JOIN uzivatele AS u ON f.ID_Uzivatele = u.ID
AND u.Bydliste = 'IT'
Tím se vyhneš celé klauzuli WHERE a rovnou si vyfiltruješ daný JOIN. Ze svých zkušeností a z kurzů vím, že je tato možnost nejpřesnější.
Matěj
Mám tam překlep, mělo to být WHERE u.Bydliste = 'Ostrava' jako další podmínka.
Každopádně teď zkouším a zkouším
Nevěděl jsem, že za ON
podmínka může být AND.
Tahám data ze SAP databáze, kde jsou statisíce řádků a selecty potřebuji co nejrychleji.
Jen bych se chtěl zeptat jen tak offtopic - dá se v MSSQL management studiu zjistit v záložce Results ke které tabulce daný sloupec náleží ?
Nebo zda jde zapnou jakýsi "rozdělovač", který mi ukáže ve výsledcích, kde už začíná další tabulka.
Děkuji
Ja bych sloupce pojmenoval takto, podle vyznamu
uzivatele: id_uzivatel, Jmeno, Bydliste, Oddeleni, ...
faktury: id_faktura, Castka, ...
uzivatel_faktury: id_uzivatel, id_faktura
Joiny obvykle nepouzival, jenom LEFT JOIN, ale nemel bys do selectu vypsat
jmena sloupcu? Pokud se bude kryt nazev sloupce z tab a s jinym v b, tak SELECT
* bude pindat error.
Nevim, jestli bych u joinu resil AND u.Bydliste = 'IT', spis bych to dal pak do
where. Ale to bych musel testnout, co je rychlejsi. Teoreticky WHERE, protoze se
nemusi kontrolovat join s podminkou.
A potom bych teda asi pouzil treti tabulku pro propojeni uzivatel faktura. Ale
to je na uvazeni. Zhlediska rychlosti by nemel byt rozdil.
SELECT uf.id_faktura, u.jmeno, f.castka
FROM uzivatel_faktury uf
LEFT JOIN uzivatele u ON u.id_uzivatel = uf.id_uzivatel
-- nemusis premyslet nad nazvy sloupcu, protoze mas v obou tabulkach stejne pojmenovane sloupce
LEFT JOIN faktury f ON f.id_faktura = uf.id_faktura
WHERE u.Oddeleni= 'IT'
Navic bych na Oddeleni udelal extra tabulku a filtroval to pomoci id, ne (u.Oddeleni= 'IT'), o.Oddeleni= 1.
S temi sloupci a tabulkami moc nerozumim. Ale, neznam ten program...
Select vybere data z tabulek a vrati tabulku. Ktery sloupec tam chces , v jakem
poradi si definujes za SELECT slovem. Pokud tam mas *, tak to bere vsechny
sloupce. Poradi tabulek bude, jake mas definovane za FROM, ne? * pouzivaji jen
ti nejvetsi luzri
Kteri si
radi pridelavaji pozdeji problemy.
Mimochodem...
Co kdyby se uzivatel prestehoval? Ve starych fakturach budes mit novou adresu?
To je preci spatne, ne?
A co kdyby zmenil jmeno, slecna se provda. Ve starych fakturach bude figurovat
nove jmeno?
A co kdyz meni pohlavi?
K tem tabulkam, znovu jsem si to precetl... V mem pripade to funguje takto:
FROM uzivatel_faktury uf
LEFT JOIN uzivatele u ON u.id_uzivatel = uf.id_uzivatel
-- nemusis premyslet nad nazvy sloupcu, protoze mas v obou tabulkach stejne pojmenovane sloupce
LEFT JOIN faktury f ON f.id_faktura = uf.id_faktura
Otevri tabulku uzivatel_faktury. Ke kazdemu radu pridej data z uzivatele a z
faktury (resp, on tam prida jen ukazatel/pointer databaze.tabulka.radek).
Ziska jednu obri tabulku. Poradi radku bude podle tabulky uzivatel_faktury.
A na zaver posklada data do tabulky podle toho, co mas v SELECT. Jestli tam mas
GROUP BY, WHERE a tak, tak to filtruje.
Jo, jestli chces mit na konci nejake poradi, zkus pouzit ORDER BY (mysql), v msql nevim. Tam se ale tusim pise jinak jen LIMIT.
Zobrazeno 9 zpráv z 9.