Příspěvky

991

Server / Re:Struktura databáze pro sklad

« kdy: 18. 11. 2018, 19:05:11 »

To RDa:
To jsem nějak nepochopil... V sestavě může být různý počet komponent a dělat pro každou vlastní sloupec se už ukázalo jako blbost.

Asi se nechapeme, nebo ty nechapes co je databaze. Ty potrebujes ukladat 2 druhy informaci: seznam fyzickych veci, at uz sestav nebo komponent ze kterych se to sklada = produkty (Tabulka 1). A pak informaci, kolikrat se ktera vec nachazi v jine veci (Tabulka 2 - sestava), s nejakou referenci, jestli to tam bude obsazeno na vice mistech:

Kód: [Vybrat]

produkty:
1. auto
2. koleso
:

sestava:
1 2 "provozni" 4x
1 2 "nahradni" 1x
:

Kde je tady vlastni sloupec? Jsou to dve primitivni tabulky.

Ty první dva sloupce v tabulce "sestava" odkazují oba do tabulky "produkty"?

992

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 17. 11. 2018, 13:45:08 »

Na první pohled to nevidí nikdo, protože je to neformátovaná zmrdovština, ale jakmile splníte premisu, že je to zavedeno pro potřeby ručně psaných formátovaných dokumentů, ...

Dokumenty jsou ale často generované strojem. Pak je třeba, aby bylo formátování povinné.

993

Server / Re:Struktura databáze pro sklad

« kdy: 16. 11. 2018, 19:22:10 »

Zdravím,
ze studijních důvodů bych chtěl v php nahradit excelovskou tabulku kterou požíváme ve výrobe pro evidenci materiálu. Přijde mi rozumnější se učit na něčem reálném než na virtuální knihovně z tutoriálů. A to, že by mohl být výsledek i někomu užitečný poskytne i nějakou motivaci.
Prvotní pokus s vytvořením MySQL tabulky ala excelovská tabulka se ukázal jako blbost. Nastudoval jsem nějakou teorii a objevil normalizaci databáze, ale pořád moc netuším jak na to. Rozebral jsem jednu velkou tabulku na vic malých provázaných pomocí cizích klíčů. Zasekl jsem se na tom, že výrobky jsou z různých součástí o různém počtu. Mít v tabulce výrobků položku s polem součást/počet mi nepřijde správné.
...
Jde o sklad dílů a výrobků z něho. Chci databázi v které bude sklad výrobků a seznam z kterých součástí jsou vyrobené. K tomu skladovou evidenci těch součástí. Jednotlivé díly se mohou vyskytovat ve více výrobcích. A databáze by měla být rozšiřitelná. Na tom ztroskotala jedná velká tabulka ala excel...
Diky za jakékoliv nakopnutí.

Nástřel schematu:

Kód: [Vybrat]

vyrobek
- id
- name
... další vlastnosti

cast
- id
- name
... další vlastnosti

vyrobek2cast
- id_vyrobek
- id_cast
- kusů

Domnívám se, že tvůj problém je právě ten počet kusů ve vazební tabulce

994

Vývoj / Re:Zkompilovaný gcc toolchain pro Linux

« kdy: 16. 11. 2018, 18:54:10 »

Zájem by byl!

Vyšíval jsem dneska na něčem souvisejícím, takže jsem updatnul verzi na githubu, přidal nějakou doku.., tady to je:

https://github.com/jose-d/easybuild-singularity-testbench#ready-to-use-image-in-singularity-library

Je to pro HPC prostředí, takže proto tam je OFED a jiné věci které se jinde nevidí..

Dík. Prostuduju.

995

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 16. 11. 2018, 17:20:30 »

Druhou možností je dát význam i bílým znakům (nový řádek uzavře element nebo povinné odsazení při změně úrovně). Tím byste ovšem vymyslel yaml.

No však :-)

996

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 16. 11. 2018, 17:15:32 »

Ignorujete, ani po upozorneni nejste sto schopen to pojmout a furt tam cpete zbytecne koncove znacky. Kdyz pominu, ze ukazka neni validni html (a rec je o tom, proc neuspelo xhtml proti html),  pak to lze jednoduseji a citelneji napsat takto:

Kód: [Vybrat]

      <ulice>            Sokolovská
      <cislo-popisne>    100
      <cislo-orientacni> 1000
      <psc>              10000
  </osoba>
</zakaznici>

Bych to stejně zapsal takto:

Kód: [Vybrat]

<zakaznici>
    <osoba>
        <ulice>            Sokolovská
        <cislo-popisne>    100
        <cislo-orientacni> 1000
        <psc>              10000

Tak jak to dělají některé jazyky: inline je povinné ukončování, jinak se ukončí odsazováním. Přidání nové osoby perfektně čitelné.

997

Vývoj / Re:Zkompilovaný gcc toolchain pro Linux

« kdy: 16. 11. 2018, 16:38:40 »

Mám na testování Easybuildích buildů udělaný kontainer, pod OSS licencí, tak pokud by byl zájem, můžu to sem postnout..

Zájem by byl!

998

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 16. 11. 2018, 16:12:55 »

Pokud někomu vadí "zbytečné" značky na konci, tak si může příslušný úryvek napsat třeba v jazyku HAML a přímo v editoru ho zkompilovat na XML či HTML.

A nebo to napsat v tom YMLu, že jo. Jde o to, že nejde jen o psaní, ale i o čtení. A já mám sice XML rád, ale přidám se k těm, kterým to tedy čtivé nepřijde.

999

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 15. 11. 2018, 19:35:31 »

Všechno to jsou nepovinné párové tagy.

neptam se na to co to je, jen se podivuju, ze to nekdo povazuje za vhodne.

Zajímala by mě tvá argumentace ohledně absoltuní nevhodnosti tohoto.

V případě dokumentů, kde se povinně odsazuje (YML) to funguje celkem pěkně.

1000

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 15. 11. 2018, 18:47:04 »

Nevím, proč se v Javě XML nahrazuje za YML. Ale u YML mě zaujala vlastnost, že tam ty uzle nemusí být uzavřeny.
Například log v YML mohu průběžně generovat a průběžně číst, protože se nemusím ohlížet na uzavírací značky jako v XML. I v půlce uřízlý text je validní.

1001

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 15. 11. 2018, 18:41:44 »

Omyl, v html treba nebyly povinne nektere ukoncovaci tagy

To se dá snadno vyřešit tak, že se příslušný tag napíše jako nepárový.

Dotyčný zřejmě myslel něco jiného:

Kód: [Vybrat]

<p>První odstavec.
<p>Druhý odstavec.
<p>Třetí odstavec.

Což je v html regulérní konstrukce, ale xml, pokud je mi známo, něco takového nedá.

1002

Vývoj / Re:SQL dotaz pro vycteni stromu zarizeni

« kdy: 15. 11. 2018, 14:10:57 »

Pro ukládání stromu v relačních databázích se používá takzvané Traverzování kolem stromu http://zaachi.com/2009/07/18/traverzovani-kolem-stromu-1.html, https://php.vrana.cz/traverzovani-kolem-stromu-prakticky.php. Což funguje dobře a rád to používám. Drahá operace je zápis (musí se udělat několik updatů, insertů). Čtení je relativně levné, a jde udělat jedním dotazem, a dostaneš přesně to co říkáš, že chceš. Při použití triggerů to začne být supr transparentní.

Pokud si chceš zachovat stávající strukturu databáze, tak bych to asi řešil na humpoláka řadou dotazů.
- první dotaz načte kořen a získá všechny potomky, jejich id.
- druhý dotaz načten všechny potomky podle id a získá potomky potomků.
- atd.

Tedy to řešit aplikačně. Případně to zabalit do nějaké SP.

1003

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 13. 11. 2018, 14:09:09 »

Já jsem na něj před časem narazil. A na Haskellovskou akci tedy dokumentace na zabití.

Ah, pardon, trochu jsem se unáhlil. Ten problém nebyl s tím, že by byla špatná dokumentace, jako spíš s tím, že mi to nešlo nainstalovat, tak jsem se naštval. Takže asi spíše moje chyba.

1004

Vývoj / Re:Proč se v Javě XML nahrazuje YML?

« kdy: 13. 11. 2018, 13:57:13 »

Skoda, ze skoro nikdo nezna Dhall. To je skutecna inovace v konfiguracnich jazycich. Prehlednost YAMLu za mensi celkovou slozitost, overitelnost schematu lepsi nez u XML a mnohem vetsi programovatelnost jako bonus.

To bude tím, že když už ho někdo zmíní, tak o něm nic neřekne. Ani link neuvede. Já jsem na něj před časem narazil. A na Haskellovskou akci tedy dokumentace na zabití.

1005

Vývoj / Re:Typový system versus unittesty

« kdy: 09. 11. 2018, 12:51:23 »

Datovy typ je spis dvojice: mnozina hodnot a mnozina operaci, ne?

Množina operací asi nebude stačit. Ještě je třeba název kategorie pro nominální typování.

Já bych to omezil na pojmenovanou množinu hodnot. Operace běžně pracují s více hodnotama různého typu, takže by se stejná operace dala najít ve spoustě typů.

buildPerson :: Name -> Name -> Age -> Person
bmi :: Age -> Sex -> Weight -> Height -> BMI

Samozřejmě často si vystačím jen s rozhraním na základě operací. Ale ten nominální typ mi pomůže ohlídat, že tam nervu blbost.

... ale možná že "pojmenovaná množina hodnot" je to, o čem mluvím :-) Age je pojmenovaný subset Intu. Kde potřebuju Int mohu dát Age, kde potřebuju Age nemohu dát Int.