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

Stran: [1] 2 3 ... 17
1
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 17:03:29 »
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index.

Však taky indexy neslouží k popisu pořadí vkládání položek do seznamu.

2
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 16:53:16 »
Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,

Způsobů mapování objektů na relace je vícero, určitě ne jeden.

...NoSQL je v podstatě moderní reinkarnace stromových databází. Se všemi plusy: snadná práce s daty, když "lezeš po stromě" a mínusy: když potřebuješ chodit "napříč lesem" - a tedy nutností dobře navrhnout strukturu stromečků.

V DB NoSQL se používají právě ty seznamy proto, aby se tím lesem nemuselo zbytečně courat, to je pazvyk z RDB.

Takže zatímco v SQL databázi se navrhuje databáze "automaticky" a při dodržení patřičných pravidel to "nejde udělat blbě"

Naopak z důvodu nutnosti rozkladu seznamů do tabulek a vazebných tabulek je návrh RDB nepřehledný. Chybně navržených relačních modelů jsem viděl dost.

v NoSQL u složitějších případů je poměrně podstatné, jestli se člověk na začátku vývoje "strefí" do datové struktury, která bude vhodná i třeba po letech...

Např. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy, a to při odstavené DB.

...a tedy narozdíl od SQL databáze by ses tedy měl podstatně více drbat s analýzou dat, budoucích požadavků atd....

Obchodní analýza se neliší podle použité DB (když to teda nedělá relačník, který návrh systému začne od databáze). Následné mapování objektů do dokumentů je výrazně jednodušší než do relací.

Anebo daleko víc času, než jsi získal "superrychlým první návrhem", ztratíš refaktory databáze když zjistíš, že tam nějaký požadavek nejde udělat efektivně.

To už je jen chybný důsledek výše uvedeného závěru. Ale když myslíte...

3
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 14:03:49 »
PanVP:
Citace
ORM - rovnák na vohejbák.
Ne, to není rovnák na vohejbák.

Nebudu vás přesvědčovat, dle vašich uvedených názorů to nemá smysl. Uvedu jen jednu okolnost, proč objekty a RDB jsou nekompatibilní:

V objektovém modelu se velice často pracuje se seznamy, přesněji jsou v obj. modelu klíčové (kdo by to byl řekl, že?). Např. takový Smalltalk má MIMOŘÁDNOU „knihovnu“ pro práci se seznamy (což se nedá říci o většině ostatních jazyků).

Když pak taková data chcete uložit do RDB, zjistíte, že RDB NEZNÁ seznamy! Jasně, už slyším křik: „Ale když udělám SELECT něco FROM něco WHERE id_rádobyseznamu = něco, tak mám seznam.“ To ale není seznam, to je pouze podmnožina VŠECH prvků seznamů STEJNÉHO typu nasypaných do jedné krabice zvané tabulka, kterou abych získal, musel jsem je v té krabici dohledat (bez ohledu na to, zda jsem při tom použil index; ano, to je jak s tím jehličím v krabici). Takže tento seznam nebyl nikde uložený jako celek (jako např. v dokumentové DB pod jedním klíčem), ten jsem musel ad hoc sestavit, a zrovna tak jej budu muset pro uložení rozebrat. A to nezmiňuju skutečnost, že onen seznam může mít jako objekt další vlastnosti (např. předpis pro řazení), které, pokud pro ně neudělám další tabulku, nebudu mít kam uložit.

Já myslím, že pro představu tento příklad stačí.

4
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 13:20:32 »
Vetsina nevyhod relacnich databazi (ukecanost, synchronizace schematu s kodem) mizi pri pouziti rozumneho ORM.

Ale z podstaty věci to zadarmo nebude, že?

https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch

5
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 13:15:30 »
A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)

Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.

6
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 24. 06. 2021, 13:00:15 »

Ale to není vtip, to je krutá realita  ;D

Já vím, ale nechtěl jsem vám to kazit.

7
Syncopoli neznám, jde to nastavit aby to uploadovalo jen nové fotky a nemazalo smazané v telefonu?
Mohl byste poslat odkaz kde se to tu řešilo, vyhledávání mi našlo jen tuhle ten váš příspěvek.

https://f-droid.org/en/packages/org.amoradi.syncopoli/

Používá to rsync. Pokud vím, rsync ponechává nadbytečné soubory v cíli, když není uveden parametr --delete.
Odkaz se mi zde nepodařilo najít, ale pokud si pamatuju, řešilo se to tu několikrát.

8
Syncopoli. Ale to už se tu řešilo.

9
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 22. 06. 2021, 17:48:46 »
Ten neznám, sem s ním  ;D

V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.

V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.

10
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 22. 06. 2021, 12:33:39 »
Tohle relační eskamotérství mi vždy připomene, jak nám vyučující vykládal vtip, jaký je rozdíl, když se kupuje vánoční stromeček v objektovém, nebo relačním obchodu.

11
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 21. 06. 2021, 11:47:02 »
Pane Schwantnere,
nejen vlivem chybějící diakritiky se v dané úloze ztrácím, takže řešení vám neporadím, ale dám vám jednu radu:

Úplně v první řadě si vezměte papír / nějaký SW a jako krabičky si namalujte modelované entity a vztahy mezi nimi (hodí se i rozlišit asociace, agregace a kompozice, které určují rozčlenění, ale to asi nebudete vědět) - zapomeňte, že existují nějaké DB, ideálně se vžijte do situace, že RDB nikdy neexistovaly; nemusíte ani používat UML. Teprve až to budete mít zcela ujasněné, potom se můžete pokusit schéma přeprznit do relačního modelu. Návrh schématu RDB bez hotové předchozí analýzy je sice mimořádně oblíbenou disciplínou, přesto se stále jedná o amatérismus.

12
Sítě / Re:Více zařízení se stejnou IP, jeden počítač
« kdy: 15. 06. 2021, 11:39:31 »
Kód: [Vybrat]
ping -I eth1 192.168.1.1

Není problémem výběr rozhraní u pingu, ale předpokládám, že nejde nastavit na 2 oddělených rozhraních jednoho zařízení adresy ze stejné podsítě, aby ping vůbec mohl proběhnout.

13
Sítě / Re:MikroTik - divný log (DHCP?)
« kdy: 14. 06. 2021, 13:16:34 »
Nejsou mi úplně jasné počet, názvy a významy podsítí, každopádně provoz DHCP od klientů DHCP z vnitřní sítě je třeba mít povolený, tudíž když mezi pravidla 2 a 3 vložíte zvláštní pravidlo přímo pro UDP 68->67, nic nepokazíte, a z čítačů uvidíte, zda to funguje. Z logu by to tím mělo zmizet.
Jump pro oddělení provozu z WAN je v pořádku, to tam nechejte.

14
Sítě / Re:Více zařízení se stejnou IP, jeden počítač
« kdy: 14. 06. 2021, 11:45:10 »
Vidíš, kdybys měl IPv6, tak tam funguje ad:re:sa%rozhraní (minimálně pro link local adresy).

Kdyby ta IPv4 fungovala pořádně, tak je tam ta linková adresa taky.

15
Sítě / Re:Napadený Mikrotik (klientská jednotka) ISP
« kdy: 14. 06. 2021, 11:32:17 »
Když se to vezme do důsledku, tak tazatele ten lempl poskytovatel nejen ohrozil, ale ještě mu přidělal práci.

Stran: [1] 2 3 ... 17