Pokusím se odpovědět jedním příspěvkem :) Čili, tématem bylo poukázat na problematiku tak, jak ji chápu já a na co já kladu důraz. Respektive oslovit ty, kteří tento problém při své práci identifikovali a (nebo) se jej snaží řešit.
Byl jsem účastníkem mnoha projektů. Problém na KAŽDÉM z nich byl, že jsme VŽDY řešili to samé, vždy od začátku, pokaždé jinak s větší či menší mírou nějakého výsledku. Můj názor je, že ať řeším jakoukoliv databázovou aplikaci, s jakýmkoliv tématem, nacházím opakující se vzory. Viz. předchozí věta. Všechny takové aplikace mají společné entity: fyzické osoby, právnické osoby, adresy, číselník obcí, číselník názvů ulic, číselník pohlaví, ... a asi dalších (dejme tomu) 70 entit. Všechny tyto entity mohou být tedy uplatněny prakticky v každém projektu. Pro každý nový projekt nemusím vymýšlet základy. Toď 1. tvrzení.
Dále pak. Vždy se vyskytne situace, týkající se změn záznamů, jejich historie a pod. Jde o další opakující se vzor, který je dále využitelný. Problém je vymýšlet to jednou pro jednu entitu, jindy pro druhou atd. Pokaždé trochu jinak. Dal-li by se navrhnout nějaký Db model (struktura), který by byl obecný a splňoval všechny MÉ (ne vaše) požadavky, šlo by o zjednodušení celé problematiky. A jde-li to, pak to implemenovat na všechny entity v Db. Tedy navrhnout takovou strukturu tabulek, aby to bylo snadno proveditelné, pochopitelné a realizovatelné. To je ta část, nacházející se v Db. Této filosofii se musí navrhnout i odpovídající struktura business objektů. Toď 2. tvrzení.
3. tvrzením je, že data mohou být sdílena v rámci jedné Db, jedné aplikace, která s Db pracuje. A to tak, aby s ní mohli pracovat uživatelé např. v Česku, Německu, Polsku a pod. Podotýkám, že současně. Tedy tak, aby měl Čech data v češtině, Němec v němčině, Polák v polštině atd. Nebavím se o popiscích a hláškách! Tento bod bych (i z vaší strany) teď moc nepitval. Rád bych jej popsal v další úvaze a proto se dnes k němu nebudu vyjadřovat.
Pokud to všechno mám, tak by bylo vhodné nezaměřit se na konkrétní Db, ale navrhnout to tak, aby Db byla snadno zaměnitelná. Toď 4. tvrzení.
Toto základní schématické rozdělení slouží k tomu (MNĚ, NE VÁM), jak stále neobjevovat kolo. Zjednodušit a zrychlit vývojové práce. Mám-li hotové tyto základy, mohu je používat stále znovu a znovu a znovu .... a stejně a stejně a ....
Této problematice se věnuji přes 11 let. Posledních 6 let pak na plný úvazek. Jelikož neznám ani jednoho z diskutujících, je přinejmenším zvláštní, obvinit mě z toho, že vám něco prodávám. Stejně tak podsouvat mi "vykašlání se na normalizace" a "tabulky v 1. NF". Nezlobte se, ale co si já chci koupit nebo potřebuji koupit, to neovlivní žádná reklama. Ani typu "Vy zíráte, my zíráme, zářivě bílé prádlo.". To samé předpokládám i u vás. Nehledě na to, že když to nechci, tak to ani nečtu. Natož pak, abych se k tomu vyjadřoval. K tomu vás nikdo nenutí. A jak napsal @karel. Řešení již zná a má.
Celý systém je založen jak na Db, tak i na těch business objektech. Jde přinejmenším o 6 DDL, které musíte ve vašem případném projektu použít. Proto není snadné ukazovat kousky kódu. Asi vám nic neřeknou. Tu první ukázku kódu je třeba chápat jako ironii, za což se omlouvám. Dále, nezlobte se, ale náš vývoj také něco stojí. Rozumný člověk pochopí, že není možné ukazovat strukturu tabulek jen tak. Takže lze těžko popisovat implementaci, stahovat si zdrojáky z FTP a pod. Nejedná se o Open Source. Tabulky můžeme definovat tak, že mají systémovou část a datovou část. Systémová část řídí různé stavy záznamu. Datová část - to jsou už vlastní data (hodnoty a FK). Používáme uložené procedury (MS SQL). Dají se používat i parametrizované dotazy. To není problém.
Kolem roku 2000 jsem hledali pro jednoho zakaznika nahradu stavajiciho ERP systemu, na ktery byly kladeny specialni pozadavkay - dnes se tomu rika 'multitenancy'. Jednoduse receno, nakupci pracoval dopolende pro firmu A - videl data firmy A a odpoledne pracoval pro firmu B (dcerina spolecnost) a pracoval s daty firmy B.
Vsechna ta data byla spolecne v tabulkach (tedy ne jak tenkrat obvykle, tabulky pro data firmy A , tabulky dat firmy B ...atd.)
Jedina firma, ktera to tenkrat mela na systemove urovni zpracovane byla firma ProAlpha (https://www.proalpha.com/en/).
Ti meli take vsechny tabulky plne systemovych informaci, co se komu ma ukazovat (take tim samozrejme resili i ty ruzne jazyky). Aplikacni vyvojar v tom frameworku toho systemu ProAlpha nemusel nic zvlastne programovat, vsechny ty ruzne verze dat se zobrazovaly podle toho, jak se ktery uzivatel prihlasil a jak byl jeho account konfigurovan.
Samozrejme, ze kazdy SQL dotaz mel krome vlastni dotazove logiky radu dalsich 'where', ktere zohlednovaly prave aby uzivatel videl ta patricna data. Kupodivu to system nijak zvlast nezpomalovalo.
Podle me ale firma ProAlpha mela tu vyhodu, ze pouzivala (a pouziva) databazi Progress , kde pouzivali pro dotazy ten jejich 4GL jazyk - tedy vpodstate proceduralni dotazovani. Proto jejich system nemohl s zadnou jinou databazi fungovat. Jestli by to slo s nativni SQL si uprimne receno nedovedu predstavit.
Takze si myslim, ze autor zrovna nemusel vymyslet perpetuum mobile, takove pokusy v obecnejsi rovine zde uz byly.
A potom se zjisti, ze staci do policka filtru pridat %'& .... a zobrazej se libovolny data ;D. Defakto sem jeste nevidel system, kterej by resil zabezpeceni jinak, nez spolehanim se na to, ze uzivatel je BFu a o SQL vzivote nezavadil.
Čili, tématem bylo poukázat na problematiku tak, jak ji chápu já a na co já kladu důraz. Respektive oslovit ty, kteří tento problém při své práci identifikovali a (nebo) se jej snaží řešit.
A nebylo by lepsi si proto zalozit blog a tam psat blogiskove uvahy? Mozna to bude prekvapive, ale vetsina ctenaru na tento web chodi kvuli technickym informacim, a ne kvuli osobnim uvaham.
Byl jsem účastníkem mnoha projektů. Problém na KAŽDÉM z nich byl, že jsme VŽDY řešili to samé, vždy od začátku, pokaždé jinak s větší či menší mírou nějakého výsledku.
Bajecne, takze ctenari budou opet resit ten samy problem vzdy od zacatku bez ohledu na to, jestli vas clanek vysel nebo ne. Nejak mi nedochazi, proc to vlastne pisete? Co tim chcete vyresit?
Nezlobte se, ale co si já chci koupit nebo potřebuji koupit, to neovlivní žádná reklama. Ani typu "Vy zíráte, my zíráme, zářivě bílé prádlo.". To samé předpokládám i u vás.
Tady nejde o nejake ovlivnovani. Tady jde o skutecnost, ze se evidentne jedna o reklamni clanek, jelikoz text popisuje nejaky problem a jako reseni nabizi POUZE vas produkt. Ze zakona by takova reklama mela byt oznacena.
Jde přinejmenším o 6 DDL, které musíte ve vašem případném projektu použít. Proto není snadné ukazovat kousky kódu. Asi vám nic neřeknou.
Jak jsem psal vyse, ke kodu lze napsat komentar. Vsimnete si, ze napriklad v clancich Pavla Tisnovskeho jsou popsany cele procesory pro ctenare srozumitelnou formou. Vazne si myslite, ze popsat procesor je jednodussi nez 6 DDL?
Dále, nezlobte se, ale náš vývoj také něco stojí. Rozumný člověk pochopí, že není možné ukazovat strukturu tabulek jen tak
Vazne? A co by si kdo na tech hlavickach vzal? Takze jedina moznost, jak vyresit vami popsany problem je bud to vymyslet sam, nebo si koupit vase reseni?
Nejedná se o Open Source.
A proc to tedy pisete na server zamereny na open source?
stahovat si zdrojáky z FTP
Vazne? V roce 2016? Nekdo pouziva FTP pro distribuci zdrojaku?
