MSSQL - Obdoba Facebooku - výpis příspěvků na zdi - nefunkční výpis počtu liků
Ahoj, vytvářím takovou jednoduchou obdobu facebooku a blbne mi jeden SQL příkaz. Přesněji řečeno nevypíše vůbec nic, ani chybovou hlášku.
Má za úkol vypsat všechny příspěvky na zdi uživatele, jehož přezdívku zadá uživatel do textfieldu.
V DB mám tabulky libiSe, uzivatel, zed, prispevek, viz. databázový diagram.
Zde je select:
select
prispevek.prisp_id,
prispevek.datum,
(select prezdivka from uzivatel where uziv_id = prispevek.uziv_fk) as Autor,
(select count(libiSe.prisp_fk) from libiSe group by libiSe.prisp_fk) as Pocet_libiSe,
prispevek.obsah as obsah
from prispevek inner join
libiSe on libiSe.prisp_fk=prispevek.prisp_id
inner join zed on prispevek.zed_fk = zed.zed_id
where zed.uziv_fk = (select uzivatel.uziv_id from uzivatel where prezdivka='jirik1');
Popis selectu: vypíše id příspěvku, jeho datum, podle id v příspěvku jméno autora a obsah. Na konci klauzule where zajištuje to, že se vypíší jen ty příspěvky, které patří na zed uživatele ,,jirik1".
Bez zjišťování počtu liků select funguje bezchybně. Jakmile jsem ale přidal ten count na liky, příkaz nevypisuje absolutně nic,
Prosím o pomoc, děkuji.
Protože v tom subselectu ti chybí omezení na konkrétního uživatele.
Díky za odpověď.
O uživatele v tom subselectu s počty lajků vůbec nejde.
Tam jde čistě jen o ty počty lajků u daného příspěvku a je jedno, kdo ten příspěvek dal.
Zkoušel jsem ještě do toho subselectu vložit upřesnění na id příspěvku stylem
where libiSe.prisp_fk = prispevek.prisp_id,
ale ani to nepomohlo.
Tak jinak, ten subselect musí vrátit jedinou hodnotu. Pokud to jich vrací víc, tak se to nedá použít.
To jsem pochopil, ale jak to omezit aby to vypsalo jen pro ten kokrétní řádek, konkrétní příspěvek, ale ne pro konkrétního uživatele, který lajk dal?
Co tohle?
select count(*) from libiSe where libiSe.prisp_fk = prispevek.prisp_id
Bohužel pořád stejné. Žádný error, jen prázdný výpis v konzoli.
Ten subselect ti nemôže ovplyvniť hlavný select. Každopádne si tam najoinuj aj tabuľku užívateľov. Lebo je ďalší nezmysel dávať ju do subselectu a zároveň do podmienky hlavného selectu.
Ten group by v subselecte mi príde ako nezmysel, tam mala byt len where podmienka
Souhlasím s Vámi, ale zatím to různě střídám a zkouším, protože původní myšlenka bohužel nefungovala.
Tak už jsem to vykoumal :)
Tady je select:
select
prispevek.prisp_id,
prispevek.datum,
(select prezdivka from uzivatel where uziv_id = prispevek.uziv_fk) as Autor,
(select count(libiSe.prisp_fk) as Pocet_lajku from libiSe
where libiSe.prisp_fk = prispevek.prisp_id group by libiSe.prisp_fk) as Pocet_liku,
prispevek.obsah as obsah
from
prispevek
inner join zed on prispevek.zed_fk = zed.zed_id
where zed.uziv_fk = (select uzivatel.uziv_id
from uzivatel where prezdivka='petr15');
Před tím jsem měl v tom selectu buď jen where nebo jen group by. Teď jsem tam dal obojí a odstranil inner join na libiSe.
A ono to, světe div se, konečně funguje.
Děkuji vám za rady :).
Možná to funguje, ale je to šíleně neoptimalizované.
Teď, když máš desítky záznamů v DB je to fajn, ale až tam budou statisíce vět, budou k tomu současně přistupovat desítky uživatelů a ty budeš muset pro každé načtení stránky ten select spustit 50x, protože budeš mít 50 příspěvků na zdi, tak potom uvidíš, jak to bude vypadat...
V realu by na tohle jen blazen pouzil relacni DB...
Proč ne? Relacní DB je na tm výkonem pořád líp než objektové databáze. Ty se hodí tam, kde nemáš jasnou strukturu a to v tomto případě máš. Jen bys to musel navrhnout tak, aby to bylo opravdu optimální. Kdyby šlo hodně do tuhého, pak Inmemory DB.
Tohle je IMHO super kandidát na NoSQL dokumentovou DB (třeba MongoDB), kvůli možnosti ukládat přímo JSON struktury a super podpory replikace přes nody v cluster prostředi. In-memoryDB se k tomu naopak moc nehodí, páč tam bude mega moc dat a replikace přes nody je v případě Im-memoryDB kapku problematická.