Váš dokonalý průvodce SQL Joins:OUTER JOIN – část 2

Vnější spojení je dnes v centru pozornosti. A toto je část 2 vašeho konečného průvodce SQL spojeními. Pokud jste zmeškali první část, zde je odkaz.

Jak to vypadá, vnější je opakem vnitřního. Pokud však zvážíte vnější spojení tímto způsobem, budete zmateni. Navíc nemusíte uvádět slovo vnější ve vaší syntaxi explicitně. Je to volitelné!

Než se ale ponoříme do toho, proberme nuly týkající se vnějších spojení.

Nulové a OUTER JOIN

Když spojíte 2 tabulky, jedna z hodnot z kterékoli tabulky může mít hodnotu null. U INNER JOINů se záznamy s nulami nebudou shodovat a budou vyřazeny a neobjeví se ve výsledkové sadě. Pokud chcete získat záznamy, které se neshodují, jedinou možností je OUTER JOIN.

Když se vrátíme k antonymům, není to opak INNER JOINs? Ne úplně, jak uvidíte v další části.

Vše o SQL Server OUTER JOIN

Pochopení vnějších spojení začíná výstupem. Zde je úplný seznam toho, co můžete očekávat:

• Všechny záznamy, které odpovídají podmínce spojení nebo predikátu. To je výraz hned za klíčovým slovem ON, podobně jako výstup INNER JOIN. Tento problém označujeme jako vnitřní řádek .
• Hodnoty jiné než NULL z vlevo tabulka s nulovými protějšky zprava stůl. Tento problém označujeme jako vnější řádky .
• Hodnoty jiné než NULL zprava tabulka s nulovými protějšky zleva stůl. Toto je další forma vnějších řad.
• Konečně to může být kombinace všech výše popsaných věcí.

S tímto seznamem můžeme říci, že OUTER JOIN vrátí vnitřní a vnější řádky .

• Vnitřní – protože přesné výsledky INNER JOIN mohou být vráceno.
• Vnější – protože vnější řádky mohou být také vráceno.

Je to rozdíl od INNER JOIN.

VNITŘNÍ SPOJENÍ VRÁTÍ POUZE VNITŘNÍ ŘÁDY. VNĚJŠÍ SPOJE SE MOHOU VRÁTIT JAK VNITŘNÍ I VNĚJŠÍ ŘADY

Všimněte si, že jsem použil „může být“ a „může také být“. Záleží na vaší klauzuli WHERE (nebo zda někdy zahrnete klauzuli WHERE), zda vrátí vnitřní i vnější řádky.

Ale z příkazu SELECT, jak můžete určit, která je levá nebo pravá tabulka ? Dobrá otázka!

Jak zjistit, který je levý nebo pravý stůl ve spojení?

Na tuto otázku můžeme odpovědět příklady:

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1

Z výše uvedeného příkladu Tabulka1 je levá tabulka a Tabulka2 je ten správný stůl. Nyní uveďme další příklad. Tentokrát jde o jednoduchý multi-join.

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1
LEFT OUTER JOIN Table3 c on b.column2 = c.column1

V tomto případě, abyste věděli, co je vlevo nebo vpravo, nezapomeňte, že spojení funguje na 2 stolech.

Tabulka1 je stále levá tabulka a Tabulka2 je ten správný stůl. To se týká spojení 2 tabulek:Tabulka1 a Tabulka2 . Co takhle připojit se k Tabulce2 a Tabulka 3 ? Tabulka2 se stane levou tabulkou a tabulkou3 je správný stůl.

Pokud přidáme čtvrtou tabulku, Tabulku3 se stane levou tabulkou a tabulkou4 je ten správný stůl. Tím to ale nekončí. Můžeme připojit další tabulku k Tabulce1 . Zde je příklad:

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1
LEFT OUTER JOIN Table3 c on b.column2 = c.column1
LEFT OUTER JOIN Table4 d on c.column1 = d.column2
LEFT OUTER JOIN Table5 e on a.column2 = e.column1

Tabulka1 je levá tabulka a Tabulka5 je ten správný stůl. Totéž můžete udělat s ostatními tabulkami.

Dobře, vraťme se k výše uvedenému seznamu očekávaných výstupů. Můžeme z nich také odvodit typy vnějších spojení.

Typy vnějších spojení

Existují 3 typy založené na výstupech OUTER JOIN.

LEVÉ VNĚJŠÍ PŘIPOJENÍ (LEVÉ PŘIPOJENÍ)

LEFT JOIN vrátí vnitřní řádky + hodnoty jiné než NULL z vlevo tabulka s nulovými protějšky pravé tabulky. Je to tedy LEFT JOIN, protože levá tabulka je dominantní ze dvou tabulek v rámci spojení, které mají nenulové hodnoty.

LEVÉ VNĚJŠÍ PŘIPOJENÍ PŘÍKLAD 1

-- Return all customerIDs with orders and no orders

USE AdventureWorks
GO

SELECT
 c.CustomerID
,soh.OrderDate
FROM Sales.Customer c
LEFT OUTER JOIN Sales.SalesOrderHeader soh ON c.CustomerID = soh.CustomerID 

Ve výše uvedeném příkladu zákazník je levá tabulka a SalesOrderHeader je ten správný stůl. Výsledkem dotazu je 32 166 záznamů – zahrnuje vnitřní i vnější řady. Část můžete vidět na obrázku 1:

Předpokládejme, že chceme vrátit pouze vnější řady nebo zákazníky bez objednávek. Chcete-li to provést, přidejte klauzuli WHERE, která zahrne pouze řádky s nulami z SalesOrderHeader .

SELECT
 c.CustomerID
,soh.OrderDate
FROM Sales.Customer c
LEFT OUTER JOIN Sales.SalesOrderHeader soh ON c.CustomerID = soh.CustomerID
WHERE soh.SalesOrderID IS NULL

Výsledná sada, kterou jsem dostal, je 701 záznamů . Všem se líbí null OrderDate z obrázku 1.

Pokud dostanu pouze vnitřní řádky, výsledkem bude 31 465 záznamů . Mohu to udělat změnou klauzule WHERE tak, aby zahrnovala tato SalesOrderIDs které nejsou nulové. Nebo mohu změnit spojení na INNER JOIN a odstranit klauzuli WHERE.

Chcete-li zjistit, zda se kontroluje z výstupu prvního příkladu bez klauzule WHERE, shrňme záznamy.

Z výše uvedených celkových řádků s 32 166 záznamy můžete vidět, že se to kontroluje s výsledky prvního příkladu. To také ukazuje, jak funguje LEFT OUTER JOIN.

LEVÉ VNĚJŠÍ PŘIPOJENÍ PŘÍKLAD 2

Tentokrát je příkladem multi-join. Všimněte si také, že jsme odstranili klíčové slovo OUTER.

-- show the people with and without addresses from AdventureWorks
USE AdventureWorks
GO

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
LEFT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
LEFT JOIN Person.Address a ON bea.AddressID = a.AddressID
LEFT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID 

Vygenerovalo 19 996 záznamů. Část výstupu si můžete prohlédnout na obrázku 2 níže. Záznamy s hodnotou null AddressLine1 jsou vnější řady. Nad ním jsou vnitřní řádky.

PRAVÉ VNĚJŠÍ PŘIPOJENÍ (PRAVÉ PŘIPOJENÍ)

RIGHT JOIN vrátí vnitřní řádky + hodnoty jiné než NULL z zprava tabulka s nulovými protějšky levé tabulky.

PRÁVA VNĚJŠÍ PŘIPOJENÍ PŘÍKLAD 1

-- From the product reviews, return the products without product reviews
USE AdventureWorks
GO

SELECT
P.Name
FROM Production.ProductReview pr
RIGHT OUTER JOIN Production.Product p ON pr.ProductID = p.ProductID
WHERE pr.ProductReviewID IS NULL 

Obrázek 3 ukazuje 10 z 501 záznamů v sadě výsledků.

Ve výše uvedeném příkladu ProductReview je levá tabulka a produkt je ten správný stůl. Protože se jedná o RIGHT OUTER JOIN, máme v úmyslu zahrnout hodnoty Non-NULL z pravé tabulky.

Výběr mezi LEFT JOIN nebo RIGHT JOIN však závisí na vás. Proč? Protože můžete vyjádřit dotaz, ať už LEFT nebo RIGHT JOIN, a získat stejné výsledky. Zkusme to s LEFT JOIN.

-- return the products without product reviews using LEFT OUTER JOIN
USE AdventureWorks
GO

SELECT
P.Name
FROM Production.Product p
LEFT OUTER JOIN Production.ProductReview pr ON pr.ProductID = p.ProductID
WHERE pr.ProductReviewID IS NULL

Pokuste se provést výše uvedené a budete mít stejný výsledek jako na obrázku 3. Myslíte si však, že s nimi bude Optimalizátor dotazů zacházet jinak? Pojďme to zjistit v Prováděcím plánu obou na obrázku 4.

Pokud s tím nejste noví, prováděcí plán obsahuje několik překvapení.

1. Diagramy vypadají stejně a jsou:zkuste Porovnat plán zobrazení a uvidíte stejné QueryPlanHash .
2. Všimněte si horního diagramu se spojením sloučení. Použili jsme RIGHT OUTER JOIN, ale SQL Server jej změnil na LEFT OUTER JOIN. Také to přehodilo levou a pravou tabulku. Díky tomu se rovná druhému dotazu s LEFT JOIN.

Jak nyní vidíte, výsledky jsou stejné. Vyberte si tedy, který z OUTER JOINů bude pohodlnější.

Proč SQL Server změnil RIGHT JOIN na LEFT JOIN?

Databázový stroj se nemusí řídit tím, jak vyjadřujete logická spojení. Dokud dokáže produkovat správné výsledky nejrychlejším možným způsobem, provede změny. Dokonce i zkratky.

Nedělejte si z toho, že RGHT JOIN je špatné a LEFT JOIN je dobré.

PRÁVA VNĚJŠÍ PŘIPOJENÍ PŘÍKLAD 2

Podívejte se na níže uvedený příklad:

-- Get the unassigned addresses and the address types with no addresses
SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
RIGHT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
RIGHT JOIN Person.Address a ON bea.AddressID = a.AddressID
RIGHT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE P.BusinessEntityID IS NULL 

Z tohoto dotazu můžete získat 2 věci, jak můžete vidět na obrázku 5 níže:

Výsledky dotazu ukazují následující:

1. Nepřiřazené adresy – tyto záznamy mají prázdné názvy.
2. Typy adres bez adres. Typy Archiv, Fakturační a Primární adresy nemají žádné odpovídající adresy. Ty jsou ze záznamů 817 až 819.

PLNÉ VNĚJŠÍ PŘIPOJENÍ (PLNÉ PŘIPOJENÍ)

FULL JOIN vrátí kombinaci vnitřních a vnějších řádků, vlevo a vpravo.

-- Get people with and without addresses, unassigned addresses, and address types without addresses
SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
FULL JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
FULL JOIN Person.Address a ON bea.AddressID = a.AddressID
FULL JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID

Výsledková sada obsahuje 20 815 záznamů. Jak byste očekávali, je to celkový počet záznamů z výsledné sady INNER JOIN, LEFT JOIN a RIGHT JOIN.

LEFT a RIGHT JOIN obsahují klauzuli WHERE pro zobrazení pouze výsledků s nulami v levé nebo pravé tabulce.

Všimněte si, že FULL JOIN může vytvořit obrovskou sadu výsledků z velkých tabulek. Používejte ji tedy pouze tehdy, když ji potřebujete.

Praktické využití funkce OUTER JOIN

Pokud stále váháte, kdy můžete a měli byste použít OUTER JOIN, zde je několik nápadů.

Vnější spojení, která vydávají vnitřní i vnější řádky

Příklady mohou být:

• Abecední seznam zaplacených a nezaplacených zákaznických objednávek.
• Abecední seznam zaměstnanců se záznamem o prodlení nebo bez něj.
• Seznam pojistníků, kteří obnovili a neobnovili své nejnovější pojistné smlouvy.

Vnější spojení, která vydávají pouze vnější řádky

Příklady:

• abecední seznam zaměstnanců bez záznamu o opožděnosti pro ocenění za nulovou opožděnost
• seznam oblastí bez zákazníků
• seznam obchodních zástupců, kteří neprodávají konkrétní produkt
• získávání výsledků z chybějících hodnot, jako jsou data bez prodejních objednávek v daném období (příklad níže)
• uzly bez potomka ve vztahu rodič-dítě (příklad níže)

Získání výsledků z chybějících hodnot

Předpokládejme, že potřebujete vytvořit zprávu. Tento přehled musí uvádět počet dní za každý měsíc v daném období, kdy nebyly žádné objednávky. SalesOrderHeader v AdventureWorks obsahuje Data objednávky , ale nemají data bez objednávek. Co můžete dělat?

1. Vytvořte tabulku všech dat v období

Ukázkový skript níže vytvoří tabulku s daty pro celý rok 2014:

DECLARE @StartDate date = '20140101', @EndDate date = '20141231';

CREATE TABLE dbo.Dates
(
	d DATE NOT null PRIMARY KEY
)

WHILE @StartDate <= @EndDate
BEGIN
  INSERT Dates([d]) SELECT @StartDate;
  SET @StartDate = DATEADD(DAY, 1, @StartDate);
END

SELECT d FROM Dates ORDER BY [d];

2. Použijte LEFT JOIN pro výstup dnů bez objednávek

SELECT
 MONTH(d.d) AS [month]
,YEAR(d.d) AS [year]
,COUNT(*) AS NoOrderDays
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE soh.OrderDate IS NULL
GROUP BY YEAR(d.d), MONTH(d.d)
ORDER BY [year], [month]

Výše uvedený kód počítá počet dní, kdy nebyly provedeny žádné objednávky. SalesOrderHeader obsahuje data s objednávkami. Takže hodnoty null vrácené ve spojení se budou počítat jako dny bez objednávek.

Mezitím, pokud chcete znát přesná data, můžete počet a seskupení odstranit.

SELECT
 d.d
,soh.OrderDate
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE soh.OrderDate IS NULL

Nebo pokud chcete spočítat objednávky v daném období a zjistit, které datum má nulové objednávky, postupujte takto:

SELECT DISTINCT
 D.d AS SalesDate
,COUNT(soh.OrderDate) AS NoOfOrders
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE d.d BETWEEN '02/01/2014' AND '02/28/2014'
GROUP BY d.d
ORDER BY d.d

Výše uvedený kód počítá objednávky za únor 2014. Podívejte se na výsledek:

Proč zdůrazňuje 3. únor 2014? V mé kopii AdventureWorks nejsou k tomuto datu žádné prodejní objednávky.

Nyní si všimněte COUNT(soh.OrderDate) v kódu. Později si vysvětlíme, proč je to tak důležité.

Získání bezdětných uzlů ve vztazích mezi rodiči a dětmi

Někdy potřebujeme znát uzly bez potomka ve vztahu rodič-dítě.

Použijme databázi, kterou jsem použil ve svém článku o HierarchyID. Musíte získat uzly bez potomků v tabulce vztahů rodič-dítě pomocí vlastního spojení.

SELECT 
 r1.RankParentId
,r1.Rank AS RankParent
,r.RankId
FROM Ranks r
RIGHT JOIN Ranks r1 ON r.RankParentId = r1.RankId
WHERE r.RankId is NULL 

Upozornění při používání OUTER JOIN

Protože OUTER JOIN může vrátit vnitřní řádky jako INNER JOIN, může to zmást. Mohou se také vloudit problémy s výkonem. Všimněte si tedy 3 bodů níže (čas od času se k nim vracím – nemládnu, takže na to také zapomínám).

Filtrování pravé tabulky v LEFT JOIN s nenulovou hodnotou v klauzuli WHERE

Problém může být, pokud jste použili LEFT OUTER JOIN, ale filtrovali pravou tabulku s nenulovou hodnotou v klauzuli WHERE. Důvodem je, že se stane funkčně ekvivalentní INNER JOIN. Zvažte příklad níže:

USE AdventureWorks
GO

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
LEFT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
LEFT JOIN Person.Address a ON bea.AddressID = a.AddressID
LEFT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE bea.AddressTypeID = 5 

Z výše uvedeného kódu se podívejme na 2 tabulky:Osoba a BusinessEntityAddress . Osoba je levá tabulka a BusinessEntityAddress je správný stůl.

Používá se LEFT JOIN, takže předpokládá hodnotu BusinessEntityID někde v BusinessEntityAddress . Zde si všimněte klauzule WHERE. Filtruje správnou tabulku pomocí AddressTypeID =5. Úplně zahodí všechny vnější řádky v BusinessEntityAddress .

Může to být kterýkoli z těchto:

• Vývojář něco ve výsledku testuje, ale zapomněl to odstranit.
• Bylo zamýšleno INNER JOIN, ale z nějakého důvodu bylo použito LEFT JOIN.
• Vývojář nechápe rozdíl mezi LEFT JOIN a INNER JOIN. Předpokládá, že kterýkoli z těchto dvou bude fungovat, a na tom nezáleží, protože výsledky jsou v tomto případě stejné.

Kterákoli z výše uvedených 3 je špatná, ale třetí položka má další důsledky. Porovnejme výše uvedený kód s ekvivalentem INNER JOIN:

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
INNER JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
INNER JOIN Person.Address a ON bea.AddressID = a.AddressID
INNER JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE bea.AddressTypeID = 5

Vypadá podobně jako předchozí kód s výjimkou typu spojení. Výsledek je také stejný, ale měli byste si povšimnout logických hodnot ve STATISTICS IO:

Na obrázku 7 jsou první I/O statistiky z použití INNER JOIN. Celkový počet logických čtení je 177. Druhé statistiky jsou však pro LEFT JOIN s vyšší hodnotou logického čtení 223. Nesprávné použití LEFT JOIN v tomto příkladu tedy bude vyžadovat více stránek nebo prostředků ze serveru SQL Server. Proto poběží pomaleji.

Také s sebou

Pokud máte v úmyslu vytisknout vnitřní řádky, použijte INNER JOIN. V opačném případě nefiltrujte pravou tabulku v LEFT JOIN s nenulovou hodnotou. Pokud k tomu dojde, skončíte s pomalejším dotazem, než když použijete INNER JOIN.

BONUSOVÝ TIP :Tato situace také nastane v RIGHT JOIN, když je levá tabulka filtrována s nenulovou hodnotou.

Nesprávné použití typů spojení ve vícenásobném spojení

Předpokládejme, že chceme získat vše prodejci a počet objednávek produktu pro každého z nich. Zde je kód:

USE AdventureWorks
GO

SELECT
 v.BusinessEntityID
,v.Name AS Vendor
,pod.ProductID
,pod.OrderQty
FROM Purchasing.Vendor v
LEFT JOIN Purchasing.PurchaseOrderHeader poh ON v.BusinessEntityID = poh.VendorID
LEFT JOIN Purchasing.PurchaseOrderDetail pod ON poh.PurchaseOrderID = pod.PurchaseOrderID 

Výše uvedený kód vrátí jak dodavatele s nákupními objednávkami, tak dodavatele bez. Obrázek 8 ukazuje skutečný plán provádění výše uvedeného kódu.

Vzhledem k tomu, že každá objednávka má zaručený detail objednávky, bylo by lepší INNER JOIN. Je to však skutečně tak?

Nejprve mějme upravený kód s INNER JOIN.

USE AdventureWorks
GO

SELECT
 v.BusinessEntityID
,v.Name AS Vendor
,pod.ProductID
,pod.OrderQty
FROM Purchasing.Vendor v
LEFT JOIN Purchasing.PurchaseOrderHeader poh ON v.BusinessEntityID = poh.VendorID
INNER JOIN Purchasing.PurchaseOrderDetail pod ON poh.PurchaseOrderID = pod.PurchaseOrderID 

Pamatujte, že výše uvedený požadavek říká „všichni“ dodavatelé. Protože jsme v předchozím kódu použili LEFT JOIN, vrátíme dodavatele bez nákupních objednávek. Důvodem je null PurchaseOrderID .

Změna spojení na INNER JOIN zahodí všechna nulová ID objednávky. Zruší také všechna nulová ID dodavatele od Vendora stůl. Ve skutečnosti se stává INNER JOIN.

Je to správný předpoklad? Prováděcí plán odhalí odpověď:

Jak vidíte, všechny tabulky byly zpracovány pomocí INNER JOIN. Náš předpoklad je tedy správný. Ale co je nejhorší, sada výsledků je nyní nesprávná, protože nebyli zahrnuti dodavatelé bez objednávek.

Také s sebou

Stejně jako v předchozím případě, pokud máte v úmyslu INNER JOIN, použijte jej. Ale víte, co dělat, pokud narazíte na situaci, jako je tato.

V tomto případě INNER JOIN zahodí všechny vnější řádky až po horní tabulku ve vztahu. I když je vaše další připojení LEFT JOIN, nebude to záležet. Prokázali jsme to v prováděcích plánech.

Nesprávné použití COUNT() ve vnějších spojeních

Pamatujete si náš ukázkový kód, který počítá počet objednávek za datum a výsledek na obrázku 6?

Zde objasníme, proč je zvýrazněno 02/03/2014 a jeho vztah k COUNT(soh.OrderDate) .

Pokud zkusíte použít COUNT(*), počet objednávek pro dané datum bude 1, což je špatně. K tomuto datu nejsou žádné objednávky. Takže když používáte COUNT() s OUTER JOIN, použijte k počítání správný sloupec.

V našem případě soh.OrderDate může být null nebo ne. Když není null, COUNT() zahrne řádek do počtu. COUNT(*) způsobí, že bude počítat vše, včetně nul. A nakonec špatné výsledky.

Vnější spojení s sebou

Shrňme si body:

• OUTER JOIN může vrátit vnitřní i vnější řádky. Vnitřní řádky jsou výsledkem, který je podobný výsledku INNER JOIN. Vnější řádky jsou nenulové hodnoty s jejich nulovými protějšky na základě podmínky spojení.
• OUTER JOIN může být LEFT, RIGHT nebo FULL. Ke každému jsme měli příklady.
• Vnější řádky vrácené funkcí OUTER JOIN lze použít různými praktickými způsoby. Měli jsme nápady, kdy můžete tyto věci použít.
• Při používání funkce OUTER JOIN jsme také měli výhrady. Pamatujte na 3 výše uvedené body, abyste se vyhnuli chybám a problémům s výkonem.

Závěrečná část této série bude pojednávat o CROSS JOIN. Takže do té doby. A pokud se vám tento příspěvek líbí, podělte se o lásku kliknutím na tlačítka sociálních sítí. Hodně štěstí při kódování!