MySQL - spojení tabulek

[x]

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 

[Reklama]

[logikk]

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

[Jelen]

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

****/
   
 

[Jelen]

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

[logikk]

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í

[Reklama]

[Jelen]

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

[logikk]

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á :-)

[Jelen]

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

[Logik]

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

 

[x]

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.

[logikk]

- 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

[Logik]

PS: Předchozí post je muj, někdy mě to přihlásí a někdy mě a já to neřešim...