Fórum Root.cz
Hlavní témata => Server => Téma založeno: Jiří Taypan 24. 06. 2010, 18:50:32
-
Dobrý den,
mám dvě tabulky:
CREATE TABLE IF NOT EXISTS `komponenty` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`typ` enum('cpu','gpu','mb','ram','hdd','cool','fan','power') COLLATE utf8_czech_ci NOT NULL,
`jmeno` varchar(500) COLLATE utf8_czech_ci NOT NULL,
`cena` int(9) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci AUTO_INCREMENT=17 ;
--
-- Vypisuji data pro tabulku `komponenty`
--
INSERT INTO `komponenty` (`id`, `typ`, `jmeno`, `cena`) VALUES
(1, 'cpu', 'AMD Phenom II X4 @ 3 GHz', 666),
(2, 'gpu', 'ATI HD5770 1GB', 456),
(3, 'mb', 'Asus M4A79XTD EVO 790X', 54),
(4, 'ram', 'Kingston DIMM 4096MB DDR III', 45),
(5, 'hdd', 'Samsung SpinPoint F3 - 1TB', 456),
(6, 'cool', 'CoolerMaster Elite', 786),
(7, 'fan', 'Zalman CU Cooler', 486),
(8, 'power', 'PSU Seasonic 80+', 486);
-- --------------------------------------------------------
--
-- Struktura tabulky `sestavy`
--
CREATE TABLE IF NOT EXISTS `sestavy` (
`typ` enum('game','pro','office','home') COLLATE utf8_czech_ci NOT NULL,
`level` enum('1','2','3','4') COLLATE utf8_czech_ci NOT NULL,
`cpu` int(11) NOT NULL,
`gpu` int(11) NOT NULL,
`mb` int(11) NOT NULL,
`ram` int(11) NOT NULL,
`hdd` int(11) NOT NULL,
`cool` int(11) NOT NULL,
`fan` int(11) NOT NULL,
`power` int(11) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
--
-- Vypisuji data pro tabulku `sestavy`
--
INSERT INTO `sestavy` (`typ`, `level`, `cpu`, `gpu`, `mb`, `ram`, `hdd`, `cool`, `fan`, `power`) VALUES
('game', '1', 1, 2, 3, 4, 5, 6, 7, 8);
jedna tabulka obsahuje sestavy (sloupce: `typ`, `level`, `cpu`, `gpu`, `mb`, `ram`, `hdd`, `cool`, `fan`, `power`) a druhá komponenty ze kterých se sestavy skládají (sloupce: `id`, `typ`, `jmeno`, `cena`). A např. sestavy.cpu obsahuje id odpovídající komponenty.
Otázka je následující: Jak by měl vypadat dotaz vracející sestavy ovšem s id nahrazenými jmény komponent?
Předem děkuji za radu už jsem z toho zoufalej...
-
Ahoj,
tady přikládám ten SQL dotaz ;)
SELECT
ts.typ,
ts.level,
tk1.jmeno AS cpu,
tk2.jmeno AS gpu,
tk3.jmeno AS mb,
tk4.jmeno AS ram,
tk5.jmeno AS hdd,
tk6.jmeno AS cool,
tk7.jmeno AS fan,
tk8.jmeno AS power
FROM sestavy AS ts
INNER JOIN komponenty AS tk1 ON (ts.cpu = tk1.id)
INNER JOIN komponenty AS tk2 ON (ts.gpu = tk2.id)
INNER JOIN komponenty AS tk3 ON (ts.mb = tk3.id)
INNER JOIN komponenty AS tk4 ON (ts.ram = tk4.id)
INNER JOIN komponenty AS tk5 ON (ts.hdd = tk5.id)
INNER JOIN komponenty AS tk6 ON (ts.cool = tk6.id)
INNER JOIN komponenty AS tk7 ON (ts.fan = tk7.id)
INNER JOIN komponenty AS tk8 ON (ts.power = tk8.id)
A dovolím si k němu pár komentářů. Používám INNER JOIN, protože předpokládám, že pro každou sestavu musí existovat ID prvku v komponentách. A nejen protože v tabulce jsou ty sloupce NOT NULL. LEFT JOIN by bylo možné taky použít (takříkajíc pro jistotu), ale INNER JOIN je o něco rychlejší.
Nevím jestli znáš použití AS. Jedná se prostě o jedoduchý alias, pod kterým se bude daný prvek (tabulka, sloupec, spocitana hodnota, ...) dále objejovat buď v dotazu, nebo následně ve výstupní resultu.
Také nemusím pokládat nějaký dotaz s WHERE, protože v tabulce komponent máš primární klíč na ID komponenty, takže by se ti nemělo stát, že si budeš pomocí ID odkazovat na jinou komponentu než jakou chceš. Také index UNIQUE už na ID v komponentách není potřeba, protože to zajistí už samotný primární klíč.
Snad ti to pomůže :)
-
Nádhera, děkuju moc :D
i za poučný komentář :D
-
Poučnej komentář to sice je, ale úplně špatnym směrem. Správnej komentář měl znít:
Jdeš na to úplně blbě. Udělej normálně join sestavy a komponenty a nech si komponenty vypsat řádek po řádku a výsledek si seber až skriptem při vytváření stránky. Bude to mít totiž jednu velkou výhodu: až si vzpomeneš, že k sestavě patří i case, tak nebudeš muset upravovat skript někde hluboko v aplikaci, ale jen prostě přidáš danej řádek do patřičnejch tabulek.
Nemluvě o tom, co ti tendle dotaz vyplodí, když některá ze sestav bude mít např. dva harddisky (za chvíli to vzhledem k existenci SSD nebude výjimka) nebo dvě grafiky. (domácí úkol).
-
Muze si ten dotaz predelat na view http://dev.mysql.com/doc/refman/5.0/en/create-view.html a potom uz nebude treba zasahovat dovnitr "scriptu" aplikace, nybrz bude stacit jen upravit tento view :)
-
jen dodam ze je to blbe navrzene. v tabulce sestavy by rozhodne nemely byt sloupce pro kompenenty. pridat treti tabulku (id, id_sestava, id_komponent). proc? protoze >=2 komponenty jednoho typu(harddisky) v jedne sestave. a pak taky princip.
-
karlos: No jo, já sem to ani detailně nezkoumal, jen jsem viděl ten šílenej výslednej dotaz, tak jsem se proti němu ohradil. Mě ani nenapadlo, že to jde navrhnout takhle blbě... Ale napadnout mě to mělo, protože pokud z něčeho lezou šílený dotazy, pak je to blbě navržený.
withounic: To je sice pravda, ale tim stejně nevyřešíš možnost dvou hdd. A furt zůstává nevyřešenejch víc stejnech komponent.
Navíc při přidání jednoho typu komponentu muset jít měnit tabulku a z ní generovanej view prostě značí chybu v návrhu. Ať už se tu vynucenou změnu v datovym modelu se povede trochu odstínit.
A navíc ji neodstíníš dokonale, protože např. u filtrů v aplikaci budeš taky muset zavýst novej typ komponent atd. atd.
-
Snažím se sem už od včerejšího večera vložit další příspěvek, ale databáze mi hlásí pořád chybu :( že by se to podařilo až teď?
-
Že by konečně teda ten příspěvek? Zkusím to rozdělit na části :/
Ještě mě napadlo jedno doporučení, že by možná bylo lepší, kdyby tyto 2 tabulky byly spojeny přes jednu další. Pak by tabulka sestav vedla data opravdu jen o sestavách a každá sestava by měla vlastní ID jako primární klíč.
Tabulka komponent by zůstala tak jak je a třetí tabulka by obsahovala pouze 2 sloupce - ID sestavy a ID komponenty. Na této tabulce by nebyl žádný UNIQUE index, ale obyčejný INDEX přes oba sloupce. Tím by se v tabulce těchto relací mohlo objevit každé ID vícekrát. Zároveň by to umožnilo do jedné sestavy umístit větší počet například pevný disků a dokonce i stejných. Počet stejných komponent v soustavě by se dal také řešit dalším sloupcem v této tabulce a následně by bylo možné vytvořit nad ID sloupci (společně) UNIQUE index, protože pak by každá relace ID_sestavy<--> ID_komponenty byla unikátní už z logiky věci.
Současně by to i trochu zjednodušilo SQL query a starost o to, zda se ti linkují správné komponenty do správného sloupce v tabulce sestav.
-
Pokračování
Příklad query uvádím níže:
SELECT
ts.typ,
ts.level,
tk.jmeno,
tk.typ
FROM sestavy AS ts
LEFT JOIN relace AS tr ON (ts.id = tr.sestava_id)
LEFT JOIN komponenty AS tk ON (tr.komponenta_id = tk.id)
-
Uff, nechápu, proč mi to nechce ta databáze vzít najednou :(
Query v původním příspěvku mi podle Admineru trvala asi 0,055 s a tahle jenom 0,001 s. Tudíž je pak třeba zvážit, kolik v systému bude záznamů a co se vyplatí víc. Zda delší query a pak rychlejší zpracování programovacím jazykem, nebo kratší query a pak zpracování v jazyce delší. Sám bych pro malé množství záznamů v tabulkách volil první možnost, pro větší množství dat bych použil spíše tuto druhou variantu.
-
A snad už konečně i poslední část :)
Tento návrh má ale teké jednu chybku. Tato SQL query získá pro každou komponentu samostatný řádek. Takže by bylo nutné v samotném programu řešit něco jako GROUP_BY_sestava.id, protože MySQL by pak vrátila pouze jednu komponentu. Druhou možností by bylo pro každou sestavu provádět samostatný dotaz, ale to by bylo časově náročné.
-
Závěrem se omlouvám za rozkouskování, ale až u poslední části jsem zjistil, že fórum asi úplně dobře neescapuje SQL code - skoušel jsem dát to i do značky code, stejně to nepomohlo. Takže proto jsem tam i místo mezer použil podtržítka. A ano, jsem evidentně lama :D
-
jen dodam ze je to blbe navrzene. v tabulce sestavy by rozhodne nemely byt sloupce pro kompenenty. pridat treti tabulku (id, id_sestava, id_komponent). proc? protoze >=2 komponenty jednoho typu(harddisky) v jedne sestave. a pak taky princip.
Jak by tedy mela vypadat tabulka sestavy? Komponenty by zustaly tak jak jsou?
-
tak mam tohle:
CREATE TABLE IF NOT EXISTS `kombinace` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`id_sestava` int(11) NOT NULL,
`id_komponenta` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci AUTO_INCREMENT=6 ;
--
-- Vypisuji data pro tabulku `kombinace`
--
INSERT INTO `kombinace` (`id`, `id_sestava`, `id_komponenta`) VALUES
(1, 1, 2),
(2, 1, 3),
(3, 1, 5),
(4, 1, 8),
(5, 1, 6);
-- --------------------------------------------------------
--
-- Struktura tabulky `komponenty`
--
CREATE TABLE IF NOT EXISTS `komponenty` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`typ` enum('cpu','gpu','mb','ram','hdd','cool','fan','power') COLLATE utf8_czech_ci NOT NULL,
`jmeno` varchar(500) COLLATE utf8_czech_ci NOT NULL,
`cena` int(9) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci AUTO_INCREMENT=17 ;
--
-- Vypisuji data pro tabulku `komponenty`
--
INSERT INTO `komponenty` (`id`, `typ`, `jmeno`, `cena`) VALUES
(1, 'cpu', 'AMD Phenom II X4 @ 3 GHz', 666),
(2, 'gpu', 'ATI HD5770 1GB', 456),
(3, 'mb', 'Asus M4A79XTD EVO 790X', 54),
(4, 'ram', 'Kingston DIMM 4096MB DDR III', 45),
(5, 'hdd', 'Samsung SpinPoint F3 - 1TB', 456),
(6, 'cool', 'CoolerMaster Elite', 786),
(7, 'fan', 'Zalman CU Cooler', 486),
(8, 'power', 'PSU Seasonic 80+', 486);
-- --------------------------------------------------------
--
-- Struktura tabulky `sestavy`
--
CREATE TABLE IF NOT EXISTS `sestavy` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`popis_o` varchar(5000) COLLATE utf8_czech_ci NOT NULL,
`popis_pro` varchar(5000) COLLATE utf8_czech_ci NOT NULL,
`cena` int(11) NOT NULL,
`bar_game` int(11) NOT NULL,
`bar_pro` int(11) NOT NULL,
`bar_office` int(11) NOT NULL,
`bar_home` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci AUTO_INCREMENT=2 ;
--
-- Vypisuji data pro tabulku `sestavy`
--
INSERT INTO `sestavy` (`id`, `popis_o`, `popis_pro`, `cena`, `bar_game`, `bar_pro`, `bar_office`, `bar_home`) VALUES
(1, 'Popis o produktu', 'Pro koho', 25000, 1, 2, 3, 4);
a ted to zajimavejsi :) jak postavit dotaz aby vracel sestavu v nejakem normalni tvaru?
-
Ten uplne puvodni dotaz nebo navrzeni nebylo v zasade spatne. Do te doby, dokud plati, ze pro kazdou sestavu je jeden hdd atd kazda ta komponenta, tak s tim neni zadny problem....
Resit, ze co kdyz budu chtit dodelat komponentu case k sestave, ze budu muset predelavat hluboko v aplikaci, tak nevidim v tom rozdil, jestli to predelavat takto nebo takto. Pokazde predelavas.
Jak ma vypadat dotaz v pripade kombinaci uz tu nekdo zodpovedel...... proste misto toho, aby se pripojili sloupce k tabulce sestava z prava, tak se pripoji ze spod... tj misto treba 8 dalsich sloupcu v pravo, se objevi 8 nebo 7 novych radku zespod (coz je dokonce trosku neefiktivnejsi, protoze se budou na 7 radcich opakovat udaje tabulky sestavy, a pri pripojovani zprava by se nic neopakovalo.
Ale tim ti nechci motat hlavu, to je detail :D
-
V tom předělání teda rozdíl je a dosti velkej. Protože v prvním případě tam pouze vložíš další záznam do patřičný tabulky (a který sloupce se maj zobrazit si vytáhneš z db). Tady bys to musel překopat celý, včetně datový struktury.
Co se týče opakování řádek sestavy, tak samozřejmě, že jedním dotazem se vytáhnou data sestavy a druhým dotazem se vytáhnout komponenty k sestavám, dávat to do jednoho dotazu je blbina. Existujou na to i knihovny, pokud to nehcete dělat růčo (např. notorm od Jakuba Vrány todle umí dost hezky).
-
--Já bysem uděla zhruba toto:
create table komponenty (id bigint, typ_id int, nazev varchar(100))
create table typy y (id bigint, nazev varchar(100))
create table sestavy (id bigint, id_komponenty bigint, id_typ int)
create table sestavy_nazvy (id bigint, nazev varchar(50))
create view V_sestavy as
Select sestavy.id id_sestavy, sestavy_nazev.nazev,
concat(case when komponenty.id = 1 then komponenty.nazev else '' end) cpu,
concat(case when komponenty.id = 2 then komponenty.nazev else '' end) HDD
......
from
sestavy_nazev
join
sestavy
on sestavy.id = sestavy_nazev.id
join
komponenty
on
sestavy.id_komponenty = komponenty.id
group by
sestavy.id, sestavy_nazev.nazev
----------
/*****
na vracení jedný konkrétní sestavy bych napsal proceduru, která vrátí tabulku už s namlácenejma html tagama
****/
-
v tom case by v else možná mělo bejt místo '' NULL, ale nejsem si jistej, jak se to concat přesně chová, já na MySQL nedělám
-
Generovat HTML z databáze je v tomdle případě prasečina (prezentační vrstva má bejt na jednom místě).
Ten view neřeší, když bude víc HDD (spojej se bez mezery). Navíc je to zasahování do prezentační vrstvy a kromě toho se to v php (pythonu, ruby, javě, ....) udělá daleko snáž
a i lépe (např. v tabulce půjde udělat):
--------|-------------
| 500GB 7200
HDD |
| SSD 64 GB
----------------------
Přestože mám db programování rád, tak cpát všechno do databáze není nejlepší řešení
-
Generovat HTML z databáze je v tomdle případě prasečina (prezentační vrstva má bejt na jednom místě).
To jsem čekal, že mi někdo napíše, že je to prasecký. Ona je to možná i pravda, ale je i pravda, že to ušetří dost práce, bude to rychlejší, si myslim, protože to vrátí tabulku včetně toho <tr> apod a nebude muset skript procházet vrácenej rekordset po záznamech. Já taky nepíšu, že bysem vracel jako html z SQL všechno, jen tu tabulku. Bajprodukt tohohle přístupu bude i to, že když se změní něco v rámci toho pohledu, nebude už třeba šahat do skriptu, kterej tu tabulku vytváří, bude stačit jen upravit pohled.
Ten view neřeší, když bude víc HDD (spojej se bez mezery). Navíc je to zasahování do prezentační vrstvy a kromě toho se to v php (pythonu, ruby, javě, ....) udělá daleko snáž
a i lépe (např. v tabulce půjde udělat):
Já nedělám v MySQL a v MSSQL concat není, takže nemám přesně představu, jak reaguje na hodnoty NULL, nicméně pokud se dobře pamatuju, tak je v ňom možnost navolit oddělovač, takže to může být oddělený čárkou nebo \n, takže to půjde udělat taky.
Já nepolemizuju o tom, jestli je to prasečina, nebo není. Ono lejt rum do piva je taky prasečina a nemám s tím problém. Takže doufám, že to nevyznělo nějakym způsobem konfrontačně.
-
Uaaaaaaaaa. :-)
Nechci vracet jako HTML všechno, jen tu tabulku.
A to je právě to. Buď všechno (což je imho nepraktický, ale budiž), anebo nic. Co když budu chtít změnit design - to budu muset šahat i do databázový vrstvy? A co když, třeba, budu chtít do tý tabulky k názvům jednotlivejch komponent přidat odkazy na jejich vlastnosti? Nebo u nich uvýst ještě další parametry, nebo....? Co když budu chtít tu tabulku přeložit do jinýho jazyka? V tu chvíli sem s tim "inteligentnim view" někde.
--
Ano, oddělovače se daj definovat - ale view nenadefinuješ tak, aby Ti jednou vrátil takový a podruhý onaký oddělovače, jako s nim neuděláš spoustu dalších věcí...
Že to bude rychlejší? O nula nula nic, daleko větší režije bude na to vykonání joinu, než na proložení HTML tagama. A udržovatelný to bude stejně - teda spíš díky snažšímu psaní v PHP daleko lépe, jen místo do view v databázi budeš šahat do PHP skriptu. Dotazy, který předhodíš tomu generátoru tabulky se měnit nebudou.
Programování v db je velmi silnej nástroj a dokáže uspořit spoustu práce - sám ho dosti používám. Na generování GUI je to ale dosti nevhodnej nástroj a pro takový rozhodnutí by měl bejt extra důvod. A kód by měl bejt nějak logickej, tzn. buď generuju v DB gui, nebo negeneruju. Generovat kus gui tady, kus tam, kus na měsíci a kus v kravíně prasečina prostě je
Už vůbec nemluvim o tom, že ve větší firmě, kde se o grafiku stará někdo jinej než o kódění logiky bys s timdle přístupem narazil totálně, ukaž mi, kterej kodér/grafik umí pořádně SQL....
Jestli si cheš lejt rum do piva a dělat jiný prasečiny, je to tvoje volba. Nedoporučuj ale prosím takový "voloviny" :-) ale ostatním.
PS: Taky nechci působit kontroverzně, ale todle mi prostě nedá :-)
-
No, je fakt, že na hoodně velký stránky je to blbý, u menších věcí je to ale podle mě putna. Já nemluvim o designu, jen o struktuře tý tabulky. Tím, že se to vloží jako brambora je tý stránce defakto jedno, jestli se tam vloží tabulka, nebo vobrázek, když přidáš sloupce, stránce je to jedno, všechno se namatlá v pohledu. Jinak řečeno, když budeš mít těch tabulek víc, budeš muset každou řešit zvlášť (kvůli názvum sloupců), pohledy, nebo procky je tak jako tak třeba udělat kvůli bezpečnosti (i když je teoreticky možný udělat jednu proceduru, která bude generovat víc tabulek podle parametru, ale to je docela nešikovný a neúměrně složitý, psát to v SQL se podle mě neoplatí pro míň jak dvacet tabulek a ještě je to díra do bezpečnosti). Navíc k tomu co si řikal o oddělení prezentační a datový části. Ta hranice je podle mě definovaná arbitrárně, takže jestli si řekneš, že součást tabulky je její struktura a prezentace jako taková je jen, jak bude stránka vypadat, tak se do toho vlezeš. Něco jinýho by bylo, kdyby se ty data natahovaly do aplikace u uživatele, to by pak byl samozřejmě nesmysl posílat tu tabulku i s tim formátovánim
-
To kvůli bezpečnosti nechápu. Udělat to bezpečně a přitom bez zbytečnýho opakování jde velmi snadno (názvy sloupců vygeneruju jednim dotazem, data druhym a šoupnu to do procedeury). nešikovný a složitý to neni.
Samozřejmě ten dotaz je o fous jednodušší, ale veškerý úpravy tý procedury budou daleko "levnější" než toho pohledu.
Ad oddělení prezentační vrstvy: tak bys moh tvrdit, že stránka sou data a prezentace je <html> a </html>. To,
- v jaký formě ty data zobrazíš (např. pro jednu sestavu ve vertikální, víc sestav v horizontální tabulce)
- jestli ta tabulka nebude mít náhodou nějaký chytrý možnosti typu skrytí řádek (by člověk porovnal pouze ty sestavy, co chce),
- jestli povedou od jednotlivejch buněk odkazy (na parametry daný komponenty),
- jaký budou mít jednotlivý buňky či řádky css třídy
...to všechno je jednoznačně prezentační vrstva. Nacpat todle všechno do pohledu či uložený procedury by bylo
a) šílený (no, šlo by to, ale jsou pro to rozhodně vhodnější nástroje)
a za
b) blbost, pokud neni veškerej zbytek prezentační vrstvy tamtéž.
-
V tom předělání teda rozdíl je a dosti velkej. Protože v prvním případě tam pouze vložíš další záznam do patřičný tabulky (a který sloupce se maj zobrazit si vytáhneš z db). Tady bys to musel překopat celý, včetně datový struktury.
muzes me vysvetlit jako malemu diteti, v cem je tak zasadni problem toho predelavani? mezi prvnim a druhym selectem? v tom prvnim pripade, pouze pridam novy sloupec do tabulky, a upravim pak nekde select, ale co je na tyhle uprave brutalniho to nevim.
-
- je daleko jednodušší změnit a uložit php soubor než editovat definici view (u souboru stačí změnit soubor, u view se musíš připojit do databáze, vytáhnout si definici patřičnýho view, upravit a vložit do databáze novou definici)
- při chybě dají programovací jazyky většinou daleko srozumitelnější chybovou hlášku než sql parser
- SQL kód lze daleko hůře strukturovat (není tam žádná možnost třídění dle adresářů - max některý db maj schémata, což je jen jedna úroveň, tříd, namespaců....), takže vyhledání patřičnýho kusu kódu v sql je složitější než u programovacího jazyka
- existence view v mnoha databázích znamená nemožnost modifikace podřízený tabulky (todle je ake pravda to nejmenší, zaprve tam člověk má většinou jiný view, zadruhý jak na tom je mysql nevim, ta je zrovna dosti benevolentní)
- databázovej kód se hůře testuje
- deployment souboru znamená jeden commit do repository a jeden příkaz na stáhnutí repozitory na server, deployment změny databáze se dělá daleko hůř (většinou to znamená napsání ručního skriptu pro upgrade databáze, byť do nějakýho mustru a spuštění nějakýho skriptu na serveru)
- rollback slepé vývojové větve (todle se mi nepovedlo, vrátim se k fční verzi a začnu znova) se u souborů dělá velmi snadno, u databáze daleko složitěji
následující body sice na první pohled s tim nesouvisej, ve výsledku však vedou k zesložitění kódu a tím pádem ke kódu, kterej se neupravuje jednoduše
- jak jednoduše vyřešíš escapování speciálních html znaků?
- ve view nemůžeš použít konstanty ani další parametry a pod. ze skriptovacích souborů (např. na generování správnejch jmen css tříd)
- ve view nemůžeš jednoduše zařídit automatickej překlad gettextem
-
PS: Předchozí post je muj, někdy mě to přihlásí a někdy mě a já to neřešim...