1. Fórum Root.cz
  2. Profil horalhoralhora
  3. Zobrazit příspěvky
  4. Příspěvky

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 - horalhoralhora

Stran: [1]
1
Vývoj / Re:Zobrazeni vztahu rodic/potomek pomoci optgroup
« kdy: 17. 03. 2020, 19:27:10 »
Snazim se o to v Reactu...

Pomoci ul/li by to vypadalo nejak takto

Kód: [Vybrat]

<ul>ELECTRONICS
<ul>TELEVISIONS
    <li>TUBE</li>
    <li>LCD</li>
    <li>PLASMA</li>
    </ul>
   
    <ul>PORTABLE ELECTRONICS
    <ul>MP3 PLAYERS
        <li>FLASH</li>
    </ul>
        <li>CD PLAYERS</li>
        <li>2 WAY RADIOS </li>
    </ul>
</ul>

2
Vývoj / Zobrazení vztahu rodič/potomek pomoci optgroup
« kdy: 17. 03. 2020, 18:44:55 »
Pro navigaci na strankach bych rad pouzil model uvedeny na (http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql)
vysledkem v databazi je

Kód: [Vybrat]
+----+----------------------+-----+-----+
| id | name                 | lft | rgt |
+----+----------------------+-----+-----+
|  1 | ELECTRONICS          |   1 |  20 |
|  2 | TELEVISIONS          |   2 |   9 |
|  3 | TUBE                 |   3 |   4 |
|  4 | LCD                  |   5 |   6 |
|  5 | PLASMA               |   7 |   8 |
|  6 | PORTABLE ELECTRONICS |  10 |  19 |
|  7 | MP3 PLAYERS          |  11 |  14 |
|  8 | FLASH                |  12 |  13 |
|  9 | CD PLAYERS           |  15 |  16 |
| 10 | 2 WAY RADIOS         |  17 |  18 |                                                                                                                                                                                                   
+----+----------------------+-----+-----+   

Vysledny JSON je nasledujici:

Kód: [Vybrat]

                {
                    "name": "ELECTRONICS",
                    "lft": "1",
                    "rgt": "20"
                },
                {
                    "name": " TELEVISIONS",
                    "lft": "2",
                    "rgt": "9"
                },
                {
                    "name": "  TUBE",
                    "lft": "3",
                    "rgt": "4"
                },
                {
                    "name": "  LCD",
                    "lft": "5",
                    "rgt": "6"
                },
                {
                    "name": "  PLASMA",
                    "lft": "7",
                    "rgt": "8"
                },
                {
                    "name": " PORTABLE ELECTRONICS",
                    "lft": "10",
                    "rgt": "19"
                },
                {
                    "name": "  MP3 PLAYERS",
                    "lft": "11",
                    "rgt": "14"
                },
                {
                    "name": "   FLASH",
                    "lft": "12",
                    "rgt": "13"
                },
                {
                    "name": "  CD PLAYERS",
                    "lft": "15",
                    "rgt": "16"
                },
                {
                    "name": "  2 WAY RADIOS",
                    "lft": "17",
                    "rgt": "18"
                }

Rad bych pomoci select - optgroup zobrazil "mnozinu potomku" kazdeho rodice. Bohuzel si moc nevim rady jak logicky postupovat tak abych do budoucna zobrazil "nekonecny" pocet vnoreni.




3
Vývoj / Re:MariaDB JOIN pro mnozinu v poli typu JSON
« kdy: 18. 02. 2020, 13:32:16 »
ok :)

4
Vývoj / MariaDB JOIN pro množinu v poli typu JSON
« kdy: 18. 02. 2020, 13:14:51 »
V tabulce "products" jsem pouzil datovy typ JSON pro pole "used_materials" ktere obsahuje id vsech pouzitych materialu

Kód: [Vybrat]
Products:
=================================
product_name(varcharc) | used_materials(json/text)
      Product A                 | [1,2,3]
Kód: [Vybrat]
Materials:
=================================
id | material_name
1  | wood
2  | cotton
3  | concrete

Mohl by mi nekdo poradit jak muzu udelat JOIN a prelozit ID v poli products.used_materials?
Chtel jsem se vyhnout vazebni tabulce mezi "products" a "materials"...

5
Vývoj / Re:Ukládání vícejazyčných verzí v MariaDB
« kdy: 28. 01. 2020, 11:23:13 »
Citace: Miroslav Šilhavý  27. 01. 2020, 18:50:48
Z hlediska DB je správné udělat dvě (možná tři) řešení. Buďto přidávat sloupce, (do sloupce pole), nebo to vše navázat. Pokud se jedná jen o EN a CZ a další jazyk je nepravděpodbný, udělal bych to jako slopec navíc. Kdyby to mělo být obecnější pak, vazbou:

CREATE TABLE product_translation(jazyk varchar, description text) a do něj vložit "CZ", "toto je český popis" a "EN", "this is an English description".

Dokonce to můžete zobecnit nad celou DB pomocí UUID třídy, tabulky a záznamu. Databáze si s tím pak dokáže poradit stoprocentně lépe, než Vaše vymýšlení "optimalizací". Dá se říct, že cokoliv Vás napadne jako struktura, dokáže DB zobecnit - tak se nesnažte jít proti tomu :).


Pokud se nepletu tak u druheho reseni

Kód: [Vybrat]
CREATE TABLE product_translation(jazyk varchar, description text) a do něj vložit "CZ", "toto je český popis" a "EN", "this is an English description".
bude full-text indexovat i anglictinu a vyhledavani  to muze zpomalovat. I kdyz uz 18 000 radku to asi nebude zase takova katastrofa. Pridani sloupcu je pro danou situaci asi lepsi. Indexy pridanych sloupcu budou obsahovat jen slova, ktera se vztahuji k dane jazykove mutaci. Souhlas?

6
Vývoj / Ukládání vícejazyčných verzí v MariaDB
« kdy: 27. 01. 2020, 15:10:12 »
Aktualne mam tabulku pro ukladani produktu v jednoduche podobe:

Kód: [Vybrat]
products:
id,productName(varchar 120), description(text), descriptionLong(text), descriptionInternal(text), warehouseInstructions(text), width(double), height(double), long(double)

Pole productName,description,descriptionLong,descriptionInternal pouzivaji full-text index. Polozek je neco kolem 9000.
Do budoucna se nepredpoklada pridani dalsiho prekladu.

Je z hlediska vykonu fulltextu lepsi do stavajici tabulky pridat pole pro preklad nebo rozdelit tabulky na

Kód: [Vybrat]
products:
id, width(double), height(double), long(double)

Kód: [Vybrat]
productDesc_cz:
id,productId,productName(varchar 120), description(text), descriptionLong(text), descriptionInternal(text),

Kód: [Vybrat]
productDesc_en:
id,productId,productName(varchar 120), description(text), descriptionLong(text), descriptionInternal(text),

 

7
Sítě / Už někdo používá nftables?
« kdy: 07. 01. 2020, 17:31:18 »
Podelil by se nekdo o dojmy z realne praxe? Nejaky klady, zapory....
Diky

8
Vývoj / Re:Ukládání různých typů produktů do databáze
« kdy: 19. 12. 2019, 12:14:58 »
Citace: RDa  19. 12. 2019, 11:47:29
Citace: horalhoralhora  19. 12. 2019, 11:31:16
U tohohle reseni
Kód: [Vybrat]
Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

Ono to ale optimalne popisuje vas sparse data model, takze nemejte obavy o vykon. Pokud hledate "attr like %x%", tak vam zadna databaze nevyjde jako vyslovene lepsi. S ohledem na mnozstvi dat ktere mate, se nejedna o nijak kriticke rozhodnuti jak to udelat - takze doporucuji si svuj dataset natahnout do toho EAV a udelat vykonnostni testy - pak zjistite, kolik lidi jste schopen obslouzit.

Cileni na vykon musi byt konkretizovano - at vite ceho chcete dosahnout. Po urcitou hranici si vystacite s pouzivanim DB jak jsou, ale jestli chcete dosahnou milisekundove latence pro hledani mnohamilionoveho datasetu, musi se na to jit samozrejme jinak.

Dobre. Pokud by tedy schema vypadalo napriklad nejak takto:

Kód: [Vybrat]
produkt[id]
atributy[id,nazev,hodnota]
hodnotyAtributu[id,id_atribut,hodnota]
atributyProduktu[id, produkt_id, id_atribut, id_hodnota]

je lepsi pro kazdou hodnotu, ktera muze byt ulozena v "hodnotyAtributu"  definovat vsechny pouzite datove typy?
tzn. hodnotaString[string],hodnotaInt[int],hodnotaDouble[double] atd...

9
Vývoj / Re:Ukládání různých typů produktů do databáze
« kdy: 19. 12. 2019, 11:31:16 »
Citace: RDa  19. 12. 2019, 11:06:09
Citace: horalhoralhora  19. 12. 2019, 10:28:21
Chapu, ze jeden ze zakladu SQL je pevne stanovene schema.

A brani vam nekdo vytvorit tabulky:
Kód: [Vybrat]
Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu
?

Trocha premyslejte, vy "pevne schema".

Omlouvam se za to "pevne schema". Myslel jsem tim ukladani hodnot atributu do sloupcu, ktere jsou jasne definovany ne na radku coz je pripad prave EAV tabulek. Cemu jsem se chtel vyhnout je
Kód: [Vybrat]
Produkty
AtributyProduktuMobilniTelefony
AtributyProduktuOsvetlovaciTechnika
atd...

U tohohle reseni
Kód: [Vybrat]
Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

10
Vývoj / Re:Ukládání různých typů produktů do databáze
« kdy: 19. 12. 2019, 10:28:21 »
Chapu, ze jeden ze zakladu SQL je pevne stanovene schema. Kvuli pozadavku snadne rozsiritelnosti jsem zacal premyslet o nerelacni databazi. V pripade SQL bych mel misto EAV tabulky pouzit tabulku pro kazdou skupinu produktu nebo jednu velkou tabulku, kde jsou vsechny atributy. Existuje lepsi zpusob pro SQL?


11
Vývoj / Ukládání různých typů produktů do databáze
« kdy: 18. 12. 2019, 18:17:44 »
Potrebuji pomoct s rozhodnutim pro nasledujici zadani:
  • 15 000 produktu
  • 100 kategorii/typu, kazda kategorie vyzaduje vlastni skupinu produktovych vlastnosti (atributu)
  • filtrovat produkty ve skupine podle zadanych atributu
  • dve jazykove mutace

Hlavni pozadavky jsou:
  • pridavat atributy produktu, bez nutnosti zmeny db schematu
  • moznost filtrovat atributove vlastnosti produktu

Pro SQL-MariaDB, jsem dosel k nazoru, ze EAV reseni je "nejpohodlnejsi" a lehce skalovatelne pro budouci potreby pridavat dalsi produktove atributy. Ovsem co se vykonu tyce v pripade potreb filtrovani (v kontextu kategorie X), mam obavu, ze je to ten horsi zpusob.

Pro toto zadani se jevi jako vhodnejsi nerelacni databaze (Mongo), ktera by mela zadani i hlavni pozadavky lepe uspokojit v pripade, ze objekt typu produkt neni casto menen uzivateli. Preklady jednotlivych poli a doprovodnych textu bych ukladal primo do objektu typu "produkt".

Pro oba pripady by platilo predvytvoreni produktove stranky pro zakaznika v okamziku vytvoreni produktu. Produktova stranka by se pak doptavala na aktualni stav skladu.   

Dava v teto situaci smysl vydat se cestou nerelacni databaze? Nekdo kdo neco podobneho resil a podelil by se teorii iplementace?
 





12
Vývoj / React - dynamické routování
« kdy: 02. 07. 2019, 13:41:36 »
Zacal jsem se ucit React, ale kvuli nulove praxi bych potreboval poradit jestli je nasledujici navrh implementace spravny, pripadne poradit jak jinak resit nasledujici situaci

V produktove databazi mam neco kolem 200 000 produktu a neustale se menici sekce menu. Na kazdy produkt se potrebuji doptat nasledovne
http://domena/produkt_cpu_ventilator

K produktum se da pochopitelne take dojit pomoci ruznych "view/menu"
http://domena/notebooky/nahradni_dily
Obsahujici:
<produkt_cpu_ventilator><produkt_cpu_velky_ventilator> atd...

Nasledujici zjednoseny kod, predstavuje mozne reseni
Kód: [Vybrat]
import React from 'react';
import './App.css';
import {
  BrowserRouter as Router,
  Route
} from 'react-router-dom';
import ShowProduct from './components/showProduct.js'
import ShowSection from './components/showSectionjs'

const PageLocator=({var1})=>{

        {/* determine from rest API if requested path is type of product or section

        if product */}   
        return <div><ShowProduct product={var1.path} /></div>


        {/* if section */}
        return <div><ShowSection section={var1.path}     

        {/* if etc...  */}
}

class App extends React.Component {


  render() {
    return(
                  <Router>
                    <div>
                        <PageLocator path="/" var1={{path:window.location.pathname}} />
                    </div>
                  </Router>

    )
  }
}

export default App;





Je takove reseni rozumne? Nabizi se pro tuto situaci lepsi reseni?








13
Vývoj / MySQL - určení hierarchie potomka
« kdy: 06. 06. 2019, 13:13:21 »
V prikladove tabulce bych potreboval urcit "top rodice" "potomka"

Kód: [Vybrat]
+----+-----------+----------+
| id | parent_id | child_id |
+----+-----------+----------+
|  1 |         4 |        5 |
|  2 |         4 |        3 |
|  3 |         3 |        1 |
+----+-----------+----------+

tzn: child_id 1 -> 3 -> 4 [top_rodic]

Vubec me nenapada jake query pouzit s ohledem na vykon. Poradi by nekdo?

14
Server / OpenSSL: může CRT obsahovat jiné informace než CSR?
« kdy: 02. 05. 2019, 19:11:22 »
Zdravim
muze openssl zmenit v prubehu generovani certifikatu z csr  hodnoty treba jako C/ST/O? Vysledny certifikat by pak obsahoval jine hodnoty nez bylo uvedeno v csr...

15
Vývoj / Zpracování XLSX v PHP/Java
« kdy: 11. 04. 2019, 18:08:48 »
Jakou knihovnu/postup pouzivate v PHP nebo v Jave pro zpracovani XLSX souboru? Jde mi o zpracovani souboru, ktery uzivatel nahraje. Aktualne v php provadim volani libreoffice pro prevod do CSV a s vyslednym souborem dal pracuji coz asi neni uplne nejlepsi reseni. Sdilel by nekdo svoje implenetovane reseni? Aspon pouzite knihovny


Diky

Stran: [1]