reklama

Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Nová témata / Nemužu spojit Lubuntu s windows 10
« Poslední příspěvek od Akrej kdy Dnes v 01:04:14 »
Zdravím

Potřebuju zasiťovat doma dva notebooky a nejsem zkušeny linuxak. Ale zkusil jsem rozchodit na Lubuntu sambu s protokolem pro win ale nekomunikuje to spolu a uplně stejně lubuntu nevidí win v siti. Děkuji za radu.
2
Vývoj / Re:Návrh relační databáze
« Poslední příspěvek od Kit kdy 25. 04. 2019, 23:22:17 »
Filip, Kit:
Grafové a jiné nosql databáze jsou sice dobré, ale do té doby, než s nima chce člověk pracovat v součinnosti s věcma, které má v SQL databázi. Např. proto se prosazují "in-databaze" fulltexty, protože fulltext mimo databázi může být nakrásně rychlejší, lepší a nevím co, ale když chceš kromě fulltextu filtrovat ještě podle dalších X kritérií, tak je to na palici. Navíc rozdělení dat do dvou databází musíš řešit takové lahůdky, jako synchronizace transakcí atd. atd....
A protože se na většinu věcí SQL hodí hodně dobře, zpravidla je lepší cesta používat nosql rozšíření SQL databází - např. ten json sloupec - než data dělit do dvou různých databází, anebo se zcela zbavovat možností SQL (a ukládat vše do noSQL databáze).

Pokud někdo chce prznit relační databázi nějakým EAV a ORM, tak mu rovnou doporučím NoSQL, kde tyhle dva nesmysly nebude potřebovat. Takový vývojář si relační databázi ani nezaslouží.
3
Vývoj / Re:Python bytearray to string
« Poslední příspěvek od S B kdy 25. 04. 2019, 23:08:42 »
Přičemž „jednou proměnnou“ byl nejspíš myšlen název proměnné, nebyl?

Pochopitelně že ano. Vnitřní implementace jazyku s tím nemá co dělat.
4
Vývoj / Re:Návrh relační databáze
« Poslední příspěvek od redustin kdy 25. 04. 2019, 23:04:21 »
Umím ocenit teorii, když má opravdu hodnotu. Třeba o jejím významu pro SQL ani o DB nijak nepochybuji. Nicméně dle mého názoru je celá řada návrhových vzorů úplně normální řešení, které každý slušnější vývojář použije, protože mu přijde správné a samozřejmé a vůbec nemusí ani tušit, že to má nějaký odborný název. Taková teorie jde mimo mě. Zrovna tenhle princip EAV je jedno z těch úplně normálních řešení.

V roce 2003 moc hotových ORM v javě nebylo, obzvláště ne s výkonově optimalizovanou podporou ACL pro read/write/delete/link/grant na úrovni jednotlivých objektů a z nich poskládaných stromových struktur. Defakto adresářová struktura s ACL, původně to sloužilo jako DMS pro přímé propojení se sambou - přístup přes file manager i přes prohlížeč. Dneska už práva na objektech tolik neřešíme, je to spíš na byznys vrstvě, ale občas jsou potřeba.

Design/vývoj javovského ORM 1 hodně šikovný člověk cca půl roku, způsob uložení dat do DB jsme měli již ověřený z dřívějšího projektu ještě v PHP (od r. 2000).

Dneska bych se podíval po něčem hotovém, ale osobně bych opět volil nějaké efektivní mapování ORM do klasického SQL, s pořádnou podporou kešování. Líbí se mi grafové databáze, ale ty principy se pomalu dostávají do SQL, což je IMO správná a užitečná cesta.
5
Vývoj / Re:Python bytearray to string
« Poslední příspěvek od S B kdy 25. 04. 2019, 23:03:46 »
Jen detaily: Jazyk python je typovany jazyk. Akorat ne staticky typovany...

Jazyky používající zasílání zpráv považuju za netypované, ale to tu teď nechci řešit, podstata je jasná.
6
Vývoj / Re:Python bytearray to string
« Poslední příspěvek od S B kdy 25. 04. 2019, 22:59:54 »
Rozhodně bych tu praktiku nevázala jen na dynamické jazyky. Třeba Rust je strong typed jazyk, ve kterém je variable shadowing nejen povolený a běžně používaný, ale v některých případech i vyloženě žádoucí (shadowing proměnné sama sebou se používá na zrušení mutability)

1. Kolik jazyků to má?
2. Není to další rovnák na ohýbák?
7
Studium a uplatnění / Re:Ktorým smerom ďalej?
« Poslední příspěvek od alex6bbc kdy 25. 04. 2019, 22:44:07 »
Srdce ti napovi kam mas jit.
vyber si tezsi cestu.
8
Studium a uplatnění / Ktorým smerom ďalej?
« Poslední příspěvek od mg kdy 25. 04. 2019, 22:27:55 »
Zdravím všetkých,

opíšem v krátkosti situáciu: mám 23 rokov a po škole som začínal ako IT Support v malej firme (+on-site technik v prípade nutnosti výmeny HW), na tejto pozícií som bol viac ako tri roky. Neskôr som sa presťahoval a začal pracovať ako IT Consultant (správa pridelených aplikácií) v korporácií. Nakoľko mi pozícia nevyhovuje (väčšinou riešim úlohy v rámci change managementu/procesov, pokiaľ je technický problém tak väčšinou iba s dodávateľom..) rozhodol som sa po menej ako roku zmeniť prácu, nakoľko hľadám niečo viac technicky zamerané.

V posledných rokoch som používal tieto technológie: MS SQL - základná administrácia, Oracle - len dáta, Win 2008 R2, 2012 R2, 2016, IIS - základy, AD, Zabbix - konfigurácia a jednoduchý vývoj monitorovacích scriptov a takisto veľa času zabrali custom aplikácie (vlastné logy,konfigurácie,incidenty...).

Naskytli sa mi momentálne dve pracovné príležitosti: 1. Aplikačný administrátor pre banku - údržba softvérových aplikácií v rámci IT infraštruktúry banky (správa WIN servrov, IIS, logy, powershell/linux skriptovanie, sql - na úrovni úpravy dát..)

2. Databázový administrátor pre stredne veľkú firmu - správa a administrácia databáz - od monitoringu/incidenty/performance tuningu až po patchovanie db ...

Platovo je na tom lepšie prvá možnosť, takisto benefity a podobné srandy ponúka banka lepšie + práca vo vlastnej kancelárií NIE OPEN SPACE :D len práve v druhej ponuke vidím väčší potenciál do budúcna. V databázach mám veľké medzery, veľmi ma prekvapilo že mi by ma radi prijali, no predpokladám, že to vďaka môjmu "všeobecnému prehľadu" - z každého viem niečo málo.

Viem som mladý, možno by som to nemal až tak moc riešiť, no preda zaujímal by ma váš názor čo je podľa Vás perspektívnejšia ponuka?

Dík
9
Vývoj / Re:Návrh relační databáze
« Poslední příspěvek od Ondrej Nemecek kdy 25. 04. 2019, 22:23:36 »
Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.

Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.

(...)

No bez těch akademiků byste neměl ani SQL ani SQL databázi, takže byste se pak neměl o čem s kolegy bavit.

Ale jinak děkuji za popis. Bylo by určitě zajímavé, jak dlouho a v kolika lidech jste to řešení vyvíjeli, aby to bylo možné porovnat s alternativami.
10
Vývoj / Re:Návrh relační databáze
« Poslední příspěvek od redustin kdy 25. 04. 2019, 21:16:17 »
Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.

Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.

* tabulka objektů - klíč obj_id. Objekty jsou různých typů - class_id

* tabulka druhů/názvů atributů - klíč attrib_id

* každý typ atributu má vlastní tabulku attrib_XXX, kde XXX je jeho attrib_id. Řádky jsou hodnoty pro objekty, tedy cizí klíč obj_id na objekt. Sloupec value je textový, číslo, datum, json atd., dle konkrétního typu atributu . Atributů/tabulek jsme zatím nadefinovali cca tisíc.

* tabulka vazeb s obj_from_id, obj_to_id a opět class_id - třída vazby. Vazby mají privátní číselnou položku, která určuje např. pořadí podtémat ve výpisu jedné úrovně stromu, snadno se podle toho stromy zpracovávají.

* další tabulky pro práva, fulltext nad stringovými atributy atd.

Samozřejmě to vyžaduje ORM vrstvu v javě, přes kterou se dělají všechny změny. Ta kešuje načtené objekty, atributy, vazby. Klidně úplně všechny, od toho paměť je. Změna nejdříve transakčně zapisuje do DB, když se podaří, změní i nakešovaná data, takže to samozřejmě drží synchronizované.

Jak říkám, je to selský rozum. Ale docela se to osvědčilo a zatím moc změn nevidím potřeba. Chybí atributy u vazeb, to bude potřeba pořešit. A samozřejmě to chce nativní fulltext, klasický problém spousty projektů.
Stran: [1] 2 3 ... 10

reklama