Příspěvky

91

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 16:49:27 »

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)

Který z výše uvedených problémů to řeší?

92

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 14:34:11 »

SB:
To si asi nerozumíme. Ale když nenapíšeš v čem, tak to působí, že si radši ani rozumět nechceš :-)

Nenapíšu, nic tím nezískám. Vývoj aplikací vaším způsobem jsem byl nucen dělat roky a vracet se k tomu nechci ani myšlenkou. Užijte si to.

P. S.: Všimněte si, že vám netykám, ani jinak neříkám vole, p*čo či soudruhu. Nenapadá vás proč?

93

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 14:26:00 »

Adaptace aplikace na změnu struktury může být rovněž jednoduchá. Stačí ji řídit tokem dat z databáze - pracuje pak se starou i novou verzí bez vidliček. Dělám to tak už dlouho a je to velmi efektivní.

Přesně tak. Aplikace (server) od začátku přímo počítá s různorodostí a změnou dat (což je tak nějak z podstaty nevyhnutelným požadavkem pocházejícím ze skutečného světa). Ví, který záznam v kterém formátu ukládá a naopak čte, podle toho rekonstruuje doménový model v paměti. Mimoto si sama řeší kontrolu dat a konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba. Jakékoliv změny tedy znamenají zapracování práce s novým formátem do doménového modelu (zde neřeším GUI atd.) bez zásahů do DB.
To samé v RDB znamená upravit schéma (nedej bože předělávat procedury a ladit je), upravit data (ano, obvykle s odstávkou DB, aby se to celé nepodělalo (závisí na provedení RDB)), v aplikaci přepracovat obvykle statickou strukturu na jinou. V případě, je-li aplikace statická, pak synchronizace nasazení změn DB a aplikace.

Ale pane Logiku, ať se nehádáme: Dělejte si to, jak chcete.

94

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 13:35:04 »

SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.

Neni, je to jazyk nizke urovne abstrakce...

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

95

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 25. 06. 2021, 13:22:22 »

Pane Logiku, já si myslím, že si moc nerozumíme.

96

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.

97

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

98

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 24. 06. 2021, 14:03:49 »

PanVP:

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čí.

99

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

100

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.

101

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 

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

102

Windows a jiné systémy / Re:Upload nových fotek android -> NAS (open media vault)

« kdy: 24. 06. 2021, 12:58:40 »

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.

103

Windows a jiné systémy / Re:Upload nových fotek android -> NAS (open media vault)

« kdy: 23. 06. 2021, 11:41:38 »

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

104

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 17:48:46 »

Ten neznám, sem s ním 

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.

105

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.