reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: [1] 2 3 ... 240
1
Hardware / Re:elektronická podání s USB tokenem
« kdy: 23. 02. 2020, 12:31:13 »
Na linuxu neexistuje univerzální služba, která by umožňovala přístup k certifikátům a bezpečnostním zařízením (něco jako CryptoAPI ve Windows). Java umožňuje přístup k PKCS#11 tokenům (to je ten přístup, který používá Firefox), ale aplikace to většinou nepodporují – musel byste si příslušnou PKCS#11 knihovnu připojit do JRE, navíc i když je PKCS#11 standard, každé zařízení se chová trochu jinak. Takže bez Windows máte smůlu.

2
Vývoj / Re:MySQL rychlost filtrování
« kdy: 21. 02. 2020, 18:12:59 »
Zpracování dotazu nabere zpoždění v momentě, kdy potřebuju všechny EAV parametry spojit.

Uvědomuju si že EAV není v souladu s SQL, ale potřebuji vyhovět požadavku použití SQL.
Teď už i víte, proč je EAV špatně.

Pokud máte zadání použít špatně špatný nástroj, nemůžete se divit, že je pak i výsledek špatný…


Všechny tabulky pak spojuji následujícím postupem:

Kód: [Vybrat]
SELECT product.id,product_feature_group.name_cz from product
join product_has_feature on product_has_feature.product_id = product.id
join product_feature_group on product_feature_group.id = product_has_feature.feature_group_id
Moc nechápu, k čemu je takový dotaz dobrý. Proč potřebujete vypsat opakovaně ID produktu a k němu vždy název skupiny vlastností, která k němu patří? Pokud tohle není dotaz, který reálně používáte, napište ten konkrétní dotaz – včetně podmínek. Teprve pak se dá usuzovat, které indexy se mohou použít a jestli se ten dotaz případně nedá přeformulovat.

3
Vývoj / Re:MYSQL rychlost filtrování
« kdy: 21. 02. 2020, 15:09:23 »
Ano, to řešení je nevhodné. Nicméně v některých případech to může být nejlepší řešení.

Nenapsal jste nic o tom, jak vypadají ty dotazy a indexy. Klíčová je tahle věta:

Indexy jsou nastavené podle nejhledanějších parametrů.
To může znamenat, že se v jednom indexu najde jeden záznam, který se pak použije pro dohledání tisíce záznamů v hlavní tabulce. Nebo to může znamenat, že se v indexu najde tisíc záznamů, a ty se pak dohledají v hlavní tabulce. A také to může znamenat, že se ve třech indexech najde v každém deset tisíc záznamů, následně databáze musí udělat jejich průnik a tím získá výslednou tisícovku záznamů. Ve všech třech případech je výsledkem 1000 záznamů, ale je diametrálně odlišný způsob, jak k nim databáze dojde. Obecně je potřeba, aby vám výslednou sedu co nejvíc omezil jeden index. Jakmile dostanete z několika indexů spousty záznamů a omezí to teprve jejich průnik, je potřeba hledat jinou reprezentaci dat, tak, abyste ta data vytvářející ten průnik dostal k sobě.

4
Vidím, že si dotaz našel své odpovědi, svůj k svému…

Můžu hádat? Aplikaci spouštíte v 32bitovém subsystému a monitorovacími nástroji pak sledujete 64bitový subsystém, nebo opačně.

5
Ano, takové chování je běžné. Do schránky se přesměrovává v případě, kdy není možné se na cílové číslo dovolat. Což může být třeba i z důvodu, že je mimo signál (třeba v metru), nebo z čísla právě probíhá jiný hovor. A ano, chování hlasové schránky je konfigurovatelné.

6
Vývoj / Re:SQL: Rozdíl mezi INNER JOIN a LEFT JOIN
« kdy: 19. 02. 2020, 19:47:24 »
V relačních databázích se jako „záznam“ označuje řádek tabulky. E-mailová adresa, skupin, datum registrace a další budou spíš sloupce. Které sloupce budou ve výsledku dotazu je uvedeno za klíčovým slovem SELECT. Když chcete ve výsledku sloupec email z tabulky users, kterou máte v dotazu pojmenovanou u, přidáte do SELECTu u.email. A tak dále.

7
Vývoj / Re:SQL: Rozdíl mezi INNER JOIN a LEFT JOIN
« kdy: 19. 02. 2020, 18:45:33 »
INNER JOIN znamená, že se spojí ty záznamy, které existují v levé i pravé tabulce. LEFT (OUTER) JOIN znamená, že se vezmou záznamy z levé tabulky, a připojí se k nim záznamy z pravé tabulky, pokud existují. Pokud odpovídající záznam v pravé tabulce neexistuje, doplní se na jeho místo NULL hodnoty.

TJ. když budete mít tabulky table_A a table_B:
Kód: [Vybrat]
table_A
id | hodnota_A
1    A
2    B
3    C

table_B
id | hodnota_B
1    X
4    Y

Pokud uděláte table_A (INNER) JOIN table_B podle sloupců id, dostanete výsledek

Kód: [Vybrat]
id | hodnota_A | hodnota_B
1    A           X


Pokud uděláte table_A LEFT (OUTER) JOIN table_B podle sloupců id, dostanete výsledek

Kód: [Vybrat]
id | hodnota_A | hodnota_B
1    A           X
2    B           NULL
3    C           NULL

RIGHT JOIN by byl opačně, tj. všechny záznamy z pravé tabulky a k nim připojené existující záznamy z levé tabulky.

8
Vývoj / Re:SQL a proměná VAR
« kdy: 19. 02. 2020, 07:54:16 »
Aby vám někdo mohl poradit, musíte nejprve uvést, co je to za systém. V SQL žádné proměnné nejsou. Je to nějaké ASP.NET, nebo T-SQL pod MS SQL?

9
Vývoj / Re:MariaDB JOIN pro mnozinu v poli typu JSON
« kdy: 18. 02. 2020, 13:29:26 »
Pokud to chcete udělat rozumně, zaveďte tu vazební tabulku. Databáze s tím počítají, všechny databázové nástroje s takovými vazbami počítají.

10
Software / Re:Chromium dává kouř paměťové kartě
« kdy: 15. 02. 2020, 13:25:01 »
Já myslím, že odpověď na původní dotaz už tu dávno zazněla – Chrome je napsané tak, aby používání moderních webů na moderním desktopu bylo pro uživatele co nejpříjemnější, což znamená především to, aby web reagoval rychle. K tomu hrome využívá zdrojů, které mají dnešní desktopy dostupné. Takže na počítači s 1 GB RAM to rozhodně nebude fungovat uspokojivě, a není žádný trik, kterým byste tu chybějící RAM mohl nahradit.

11
Odkladiště / Re:Sken všech veřejných domén
« kdy: 15. 02. 2020, 09:06:27 »
a co takhle všetko crawlovat do elasticsearch clastru?
Akorát to bude chtít bohatého strýčka multimilionáře, který to zaplatí.

12
Server / Re:Freehosting s SSL zdarma
« kdy: 14. 02. 2020, 13:48:13 »
Doménu nemusíte kupovat tam, co webhosting. Často ale máte při koupi domény nějaký malý webhosting zdarma. Jinak např. SubReg má doménu .cz za 165 Kč bez DPH a k tomu můžete mít webhosting za 10 Kč měsíčně. Wedos má k doméně webhosting 100 MB zdarma, ale není tam PHP ani HTTPS. A pozor na to, že důvěryhodný certifikát není ani v tom jejich hostingu za 33 Kč, musíte si 10 Kč měsíčně připlatit. OVH má doménu .cz za 149 Kč a je u toho i webhosting 10 MB s PHP.

13
Server / Re:Cloud disk (FTP, SFTP)
« kdy: 13. 02. 2020, 23:02:52 »
Dobrý den v protokolu mám zcela jasno, potřebuji SFTP protokol nebo NFS (pro jednoduchost přiložené foto).
Dobře, v původním dotazu bylo něco jiného.

Jak jsem psal, OVH NAS umí NFS. Jinak bych zkusil googlit SFTP cloud. Asi toho bude míň, než řešení přes HTTPS, on je přeci jen SFTP protokol pro cloud nevhodný, ale Google něco najde.

14
Odkladiště / Re:scan všech veřejných domén
« kdy: 12. 02. 2020, 21:00:34 »
Podle toho, co píšete, nechcete skenovat všechny dostupné domény, ale weby. 0.0.0.0 až 255.255.255.255 nejsou domény, ale IP adresy. Na jedné IP adrese může běžet web server, který hostuje stovky různých domén. Když jejich názvy neznáte, server vám je nemusí prozradit. CZ.NIC veřejný seznam domén neposkytuje. Ve výjimečných případech poskytuje seznam domén pro nějaké studijní nebo výzkumné účely, což váš projekt nesplňuje. Navíc seznam domén by vám opět byl k ničemu – z toho, že existuje root.cz, se nedozvíte, že existuje také forum.root.cz.

To, co jste popsal jako c), je přesně ta cesta, kterou používá Google i všichni ostatní. Prostě začnete nějakým seznamem stránek a následujete odkazy. Samozřejmě tak neobjevíte vše, ale ani Google nemá zaindexované ani zdaleka vše. Akorát nezačínejte nejnavštěvovanějšími stránkami (k těm bude patřit třeba domovská stránka Googlu, a tam moc odkazů neobjevíte), spíš začněte stránkami, které mají hodně externích odkazů – katalogy, Wikipedie, agregátory, média.

15
Server / Re:Fyzické uložení dat u relačních databází
« kdy: 07. 02. 2020, 08:45:44 »
Nejmenovana databaze mela maintenance prikaz vacuum urceny prave k uklizeni bordelu po vami popsanych praktikach ,)
PostgreSQL neukládá záznamy způsobem, který jsme popsal. Neoptimální stav databáze vzniká i jinými způsoby. Např. i když ukládáte data s pevnou délkou záznamu, pokud smažete víc záznamů než přidáte, pořád vám vznikne v souboru díra. Navíc PostgreSQL je MVCC databáze, která i updatovaný řádek zapisuje na nové místo, aby původní řádek byl k dispozici ostatním transakcím a pro případný rollback. Fyzické uložení dat v PostgreSQL je popsané zde: Database Physical Storage.

Stran: [1] 2 3 ... 240

reklama