Ahoj,
porušení normální formy databáze by nemělo být dogma - už kolikrát jsem
musel volit nutné zlo v podobě redundance dat místo toho, abych omezoval
uživatele zbytečně pomalou službou. Každopádně díky za moc cenné
zkušenosti a dobré vodítko pro naši další práci!
David Mach
Dne 2.9.2010
Zdravim,
my pouzivame tiez myslienku cislo jedna, teda dotazy vo forme in
obmedzeni. Tie in obmedzenia, kym sa nejedna o tisicky idciek su uplne
vpohode.
Ale mame aj vinimku, mame totiz modul, ktory potrebuje citat udaje z mnohych
modulov naraz a ma vselijake svoje obmedzenia. Konkretne tento
Při návrhu modulární architektury je třeba brát na zřetel jiná možná
použití dat z konkrétního modulu a umožnit zásuvné či rozšiřující
submoduly do střev každého modulu.
Jestli se použije vzor Listener, Observer a nebo eLISPové hooky je
celkem buřt. Potom není nutné si tolik hrát s API, jenom
Mate pravdu, no upozornim este na porovnanie join vs in z pohladu
performancie.
Potencionalny problem in dotazov moze byt, ak by sa databaza rozhodla
prechadzat tabulku sekvencne namiesto pouzitia indexu. Ten index tam
urcite je, kedze sa jedna o foreign key. Popravde ale ocakavam, ze na
Zdravím všechny!
V naší firmě jsme doposud vyvíjeli klasické aplikace na jedné classpath
(typu vidím vše, volám vše, využívám vše, čili občas pěkná prasárna).
Nyní vyvíjíme novou modulární aplikaci postavenou na OSGi, přičemž naše
původní vize byla ta, že jednotlivé moduly mezi sebou budou
Ahoj,
my jedeme na modulárním systému asi 2 roky (s tím rozdílem, že nemáme
OSGI, ale jen zřetězené aplikační konexty Springu na stejné classpath -
nicméně už to k zavedení modulárnosti stačí). Řešili jsme stejný problém a
obávám se, že neexistuje ideální řešení. Základní pravidlo spočívá ve
