Builder.cz - Informacni server o programovani

Jen takova otazka kolem ... jste si jist, ze ta databaze uklada fyzicky ty sloupecky v poradi v jakem je do tabulky ukladate?

Jen takova otazka kolem ... jste si jist, ze ta databaze uklada fyzicky ty sloupecky v poradi v jakem je do tabulky ukladate?

Citovat příspěvek

ALTER TABLE table_name MODIFY COLUMN column_name_1 column_definition AFTER column_name_2

ALTER TABLE table_name MODIFY COLUMN column_name_1 column_definition AFTER column_name_2

Citovat příspěvek

Maaartin Napsal:
-------------------------------------------------------
> > odkdy se 250 * 8 = 4KB ?
>
> Ooops.
>
> > Jinak ve většině databází vás s fixními
> položkami nepustí za hranici stránky - a u
> starších databází ani s variabilními položkami.
> Nicméně Váš příklad neodporuje mému tvrzení - jen
> jde o jinou situaci - primárně se aplikace zpomalí
> z důvodu načítání více stránek a ne, že by PC mělo
> problém přistupovat k deserializovaným datům s
> vyšším offsetem než je 4KB.
>
> No kdyby byl kazdy radek na dve stranky, pak by
> byl / mohl byt dotaz
> SELECT prvniSloupec WHERE indexovanySloupec=42
> o dost rychlejsi nez
> SELECT posledniSloupec WHERE indexovanySloupec=42
>

kdyby byl - ale tady se bavime akademicky - protoze SELECT jeden_sloupec FROM nehorazne_siroka_tabulka je pitomost - budto to znamena neprovedenou normalizaci, nebo pokud ala OLAP - a zase pak na SQL serveru to znamena chybne zvoleny sw. To pak chce db, ktere ukladaji data do sloupcu.

Pavel

>
> > SELECT * je nejvetsi prasarmna, co muze
> nastat.
>
> Ja myslim ze az druha nejvetsi. Uplne nejvetsi je
> SELECT prvniSloupec, druhySloupec, ...,
> dvestepadesatySloupec
>
> Ale uznavam ze uvedeny problem muze nastat.
>
> http://neviditelnypes.lidovky.cz/glosa-solarni-ele
> ktrarny-podvod-stoleti-fpc-/p_ekonomika.asp?c=A100
> 715_154855_p_ekonomika_wag

Maaartin Napsal: ------------------------------------------------------- > > odkdy se 250 * 8 = 4KB ? > > Ooops. > > > Jinak ve většině databází vás s fixními > položkami nepustí za hranici stránky - a u > starších databází ani s variabilními položkami. > Nicméně Váš příklad neodporuje mému tvrzení - jen > jde o jinou situaci - primárně se aplikace zpomalí > z důvodu načítání více stránek a ne, že by PC mělo > problém přistupovat k deserializovaným datům s > vyšším offsetem než je 4KB. > > No kdyby byl kazdy radek na dve stranky, pak by > byl / mohl byt dotaz > SELECT prvniSloupec WHERE indexovanySloupec=42 > o dost rychlejsi nez > SELECT posledniSloupec WHERE indexovanySloupec=42 > kdyby byl - ale tady se bavime akademicky - protoze SELECT jeden_sloupec FROM nehorazne_siroka_tabulka je pitomost - budto to znamena neprovedenou normalizaci, nebo pokud ala OLAP - a zase pak na SQL serveru to znamena chybne zvoleny sw. To pak chce db, ktere ukladaji data do sloupcu. Pavel > > > SELECT * je nejvetsi prasarmna, co muze > nastat. > > Ja myslim ze az druha nejvetsi. Uplne nejvetsi je > SELECT prvniSloupec, druhySloupec, ..., > dvestepadesatySloupec > > Ale uznavam ze uvedeny problem muze nastat. > > http://neviditelnypes.lidovky.cz/glosa-solarni-ele > ktrarny-podvod-stoleti-fpc-/p_ekonomika.asp?c=A100 > 715_154855_p_ekonomika_wag

Citovat příspěvek

> [ital]odkdy se 250 * 8 = 4KB ?[/ital]

Ooops.

> [ital]Jinak ve většině databází vás s fixními položkami nepustí za hranici stránky - a u starších databází ani s variabilními položkami. Nicméně Váš příklad neodporuje mému tvrzení - jen jde o jinou situaci - primárně se aplikace zpomalí z důvodu načítání více stránek a ne, že by PC mělo problém přistupovat k deserializovaným datům s vyšším offsetem než je 4KB.[/ital]

No kdyby byl kazdy radek na dve stranky, pak by byl / mohl byt dotaz
SELECT prvniSloupec WHERE indexovanySloupec=42
o dost rychlejsi nez
SELECT posledniSloupec WHERE indexovanySloupec=42


> [ital]SELECT * je nejvetsi prasarmna, co muze nastat.[/ital]

Ja myslim ze az druha nejvetsi. Uplne nejvetsi je
SELECT prvniSloupec, druhySloupec, ..., dvestepadesatySloupec :D :D :D

Ale uznavam ze uvedeny problem muze nastat.

> [ital]odkdy se 250 * 8 = 4KB ?[/ital] Ooops. > [ital]Jinak ve většině databází vás s fixními položkami nepustí za hranici stránky - a u starších databází ani s variabilními položkami. Nicméně Váš příklad neodporuje mému tvrzení - jen jde o jinou situaci - primárně se aplikace zpomalí z důvodu načítání více stránek a ne, že by PC mělo problém přistupovat k deserializovaným datům s vyšším offsetem než je 4KB.[/ital] No kdyby byl kazdy radek na dve stranky, pak by byl / mohl byt dotaz SELECT prvniSloupec WHERE indexovanySloupec=42 o dost rychlejsi nez SELECT posledniSloupec WHERE indexovanySloupec=42 > [ital]SELECT * je nejvetsi prasarmna, co muze nastat.[/ital] Ja myslim ze az druha nejvetsi. Uplne nejvetsi je SELECT prvniSloupec, druhySloupec, ..., dvestepadesatySloupec :D :D :D Ale uznavam ze uvedeny problem muze nastat.

Citovat příspěvek

JiVi Napsal:
-------------------------------------------------------
> SELECT * je nejvetsi prasarmna, co muze nastat.Na
> to netreba studovat management.
> To zvladne kde jaky jelito a taky to vetsinou tak
> funguje.

tak melo by se rozlisovat, jestli to da nekdo do kodu v aplikaci nebo proste potrebuje jednorazove vratit nejaka data. Pokud me bude zajimat 50 sloupcu z jedny tabulky, tak napisu select * a nebudu pul hodiny vyjmenovavat vsechny sloupce nebo to v necem klikat...

JiVi Napsal: ------------------------------------------------------- > SELECT * je nejvetsi prasarmna, co muze nastat.Na > to netreba studovat management. > To zvladne kde jaky jelito a taky to vetsinou tak > funguje. tak melo by se rozlisovat, jestli to da nekdo do kodu v aplikaci nebo proste potrebuje jednorazove vratit nejaka data. Pokud me bude zajimat 50 sloupcu z jedny tabulky, tak napisu select * a nebudu pul hodiny vyjmenovavat vsechny sloupce nebo to v necem klikat...

Citovat příspěvek

> No fuj. Udelat naky hnusny seznam jde rychle a ani
> na to netreba studovat management, ale pokud
> nekomu pripada cistejsi vyjmenovavat 250 sloupcu
> nez rict vsechny.... toz to pak nemam slov.


SELECT * je nejvetsi prasarmna, co muze nastat.Na to netreba studovat management.
To zvladne kde jaky jelito a taky to vetsinou tak funguje.
Pak pridela do tabulky sloupec s BLOB a uz bude taha kvatna dat a ani nebude vedet, kde vsude SELECT * uz ma.Pak se clovek divi, proc mu to jede jak snek, kdyz si na klientksou stranu taha plno nesmyslu a dat, ktera nepotrebuje.

> No fuj. Udelat naky hnusny seznam jde rychle a ani > na to netreba studovat management, ale pokud > nekomu pripada cistejsi vyjmenovavat 250 sloupcu > nez rict vsechny.... toz to pak nemam slov. SELECT * je nejvetsi prasarmna, co muze nastat.Na to netreba studovat management. To zvladne kde jaky jelito a taky to vetsinou tak funguje. Pak pridela do tabulky sloupec s BLOB a uz bude taha kvatna dat a ani nebude vedet, kde vsude SELECT * uz ma.Pak se clovek divi, proc mu to jede jak snek, kdyz si na klientksou stranu taha plno nesmyslu a dat, ktera nepotrebuje.

Citovat příspěvek

Maaartin Napsal:
-------------------------------------------------------
> > Tohle je trochu zavádějící. Samozřejmě, že
> záleží na implementačních detailech nicméně platí,
> že data se čtou z disku po datových stránkách a
> nikoliv po řádcích, případně sloupcích. Tudíž vždy
> se načte jeden nebo více kompletních řádků.
>
> No, pokud je radek podobne dlouhy jako stranka,
> taxe muze lehce stat ze se nacte jen jeho zacatek
> (a konec je na dalsi strance). Pri 250 sloupcich
> typu double se hned dostavame na 4KiB, to je afaik
> standardni velikost stranky Firebirdu. Kdyz
> predpokladame ze zacatek radku obsahuje hlavicku
> co se musi precist vzdy a nekde na konci je
> sloupec podle kteryho se filtruje, tak to muze byt
> problem.
>

odkdy se 250 * 8 = 4KB ? Jinak ve většině databází vás s fixními položkami nepustí za hranici stránky - a u starších databází ani s variabilními položkami. Nicméně Váš příklad neodporuje mému tvrzení - jen jde o jinou situaci - primárně se aplikace zpomalí z důvodu načítání více stránek a ne, že by PC mělo problém přistupovat k deserializovaným datům s vyšším offsetem než je 4KB.

Pavel
> > co vyhoda, hlavne by me zajimalo, jaky je
> problem i tech 250 sloupcu vyjmenovat?
>
> A to by zas zajimalo, k cemu to ma byt dobry. A
> kdo to bude cist.
>
> Uz bylo tisickrat receno ze skoro nikdy "SELECT *"
> neni dobry napad, ale nekdy je. V tom pripade
> mozna opravdu sces vsechny sloupce a kdyz jich
> vyjmenujes 250 a paxe vytvori dalsi tak to budes
> dopisovat rucne.
>
> > V oracle to umi PLSQL Developer.Udela Select
> , Insert s nazvama vsech sloupcu. V MSSQL to umi
> SQLmanagement studio, staci kliknout na tabulku
> pravym tlacitkem a senzma sloupcu je tu hned.
>
> No fuj. Udelat naky hnusny seznam jde rychle a ani
> na to netreba studovat management, ale pokud
> nekomu pripada cistejsi vyjmenovavat 250 sloupcu
> nez rict vsechny.... toz to pak nemam slov.
>
> http://neviditelnypes.lidovky.cz/glosa-solarni-ele
> ktrarny-podvod-stoleti-fpc-/p_ekonomika.asp?c=A100
> 715_154855_p_ekonomika_wag

Maaartin Napsal: ------------------------------------------------------- > > Tohle je trochu zavádějící. Samozřejmě, že > záleží na implementačních detailech nicméně platí, > že data se čtou z disku po datových stránkách a > nikoliv po řádcích, případně sloupcích. Tudíž vždy > se načte jeden nebo více kompletních řádků. > > No, pokud je radek podobne dlouhy jako stranka, > taxe muze lehce stat ze se nacte jen jeho zacatek > (a konec je na dalsi strance). Pri 250 sloupcich > typu double se hned dostavame na 4KiB, to je afaik > standardni velikost stranky Firebirdu. Kdyz > predpokladame ze zacatek radku obsahuje hlavicku > co se musi precist vzdy a nekde na konci je > sloupec podle kteryho se filtruje, tak to muze byt > problem. > odkdy se 250 * 8 = 4KB ? Jinak ve většině databází vás s fixními položkami nepustí za hranici stránky - a u starších databází ani s variabilními položkami. Nicméně Váš příklad neodporuje mému tvrzení - jen jde o jinou situaci - primárně se aplikace zpomalí z důvodu načítání více stránek a ne, že by PC mělo problém přistupovat k deserializovaným datům s vyšším offsetem než je 4KB. Pavel > > co vyhoda, hlavne by me zajimalo, jaky je > problem i tech 250 sloupcu vyjmenovat? > > A to by zas zajimalo, k cemu to ma byt dobry. A > kdo to bude cist. > > Uz bylo tisickrat receno ze skoro nikdy "SELECT *" > neni dobry napad, ale nekdy je. V tom pripade > mozna opravdu sces vsechny sloupce a kdyz jich > vyjmenujes 250 a paxe vytvori dalsi tak to budes > dopisovat rucne. > > > V oracle to umi PLSQL Developer.Udela Select > , Insert s nazvama vsech sloupcu. V MSSQL to umi > SQLmanagement studio, staci kliknout na tabulku > pravym tlacitkem a senzma sloupcu je tu hned. > > No fuj. Udelat naky hnusny seznam jde rychle a ani > na to netreba studovat management, ale pokud > nekomu pripada cistejsi vyjmenovavat 250 sloupcu > nez rict vsechny.... toz to pak nemam slov. > > http://neviditelnypes.lidovky.cz/glosa-solarni-ele > ktrarny-podvod-stoleti-fpc-/p_ekonomika.asp?c=A100 > 715_154855_p_ekonomika_wag

Citovat příspěvek

> [ital]Tohle je trochu zavádějící. Samozřejmě, že záleží na implementačních detailech nicméně platí, že data se čtou z disku po datových stránkách a nikoliv po řádcích, případně sloupcích. Tudíž vždy se načte jeden nebo více kompletních řádků.[/ital]

No, pokud je radek podobne dlouhy jako stranka, taxe muze lehce stat ze se nacte jen jeho zacatek (a konec je na dalsi strance). Pri 250 sloupcich typu double se hned dostavame na 4KiB, to je afaik standardni velikost stranky Firebirdu. Kdyz predpokladame ze zacatek radku obsahuje hlavicku co se musi precist vzdy a nekde na konci je sloupec podle kteryho se filtruje, tak to muze byt problem.


> [ital]co vyhoda, hlavne by me zajimalo, jaky je problem i tech 250 sloupcu vyjmenovat?[/ital]

A to by zas zajimalo, k cemu to ma byt dobry. A kdo to bude cist.

Uz bylo tisickrat receno ze skoro nikdy "SELECT *" neni dobry napad, ale nekdy je. V tom pripade mozna opravdu sces vsechny sloupce a kdyz jich vyjmenujes 250 a paxe vytvori dalsi tak to budes dopisovat rucne.

> [ital]V oracle to umi PLSQL Developer.Udela Select , Insert s nazvama vsech sloupcu. V MSSQL to umi SQLmanagement studio, staci kliknout na tabulku pravym tlacitkem a senzma sloupcu je tu hned.[/ital]

No fuj. Udelat naky hnusny seznam jde rychle a ani na to netreba studovat management, ale pokud nekomu pripada cistejsi vyjmenovavat 250 sloupcu nez rict vsechny.... toz to pak nemam slov.

> [ital]Tohle je trochu zavádějící. Samozřejmě, že záleží na implementačních detailech nicméně platí, že data se čtou z disku po datových stránkách a nikoliv po řádcích, případně sloupcích. Tudíž vždy se načte jeden nebo více kompletních řádků.[/ital] No, pokud je radek podobne dlouhy jako stranka, taxe muze lehce stat ze se nacte jen jeho zacatek (a konec je na dalsi strance). Pri 250 sloupcich typu double se hned dostavame na 4KiB, to je afaik standardni velikost stranky Firebirdu. Kdyz predpokladame ze zacatek radku obsahuje hlavicku co se musi precist vzdy a nekde na konci je sloupec podle kteryho se filtruje, tak to muze byt problem. > [ital]co vyhoda, hlavne by me zajimalo, jaky je problem i tech 250 sloupcu vyjmenovat?[/ital] A to by zas zajimalo, k cemu to ma byt dobry. A kdo to bude cist. Uz bylo tisickrat receno ze skoro nikdy "SELECT *" neni dobry napad, ale nekdy je. V tom pripade mozna opravdu sces vsechny sloupce a kdyz jich vyjmenujes 250 a paxe vytvori dalsi tak to budes dopisovat rucne. > [ital]V oracle to umi PLSQL Developer.Udela Select , Insert s nazvama vsech sloupcu. V MSSQL to umi SQLmanagement studio, staci kliknout na tabulku pravym tlacitkem a senzma sloupcu je tu hned.[/ital] No fuj. Udelat naky hnusny seznam jde rychle a ani na to netreba studovat management, ale pokud nekomu pripada cistejsi vyjmenovavat 250 sloupcu nez rict vsechny.... toz to pak nemam slov.

Citovat příspěvek

peta1 Napsal:
-------------------------------------------------------
> Pavel Stehule - Vychazim z uvahy, ze kdyz neco
> programujes a prochazis pole, zacinas for
> (i=0;i> umisteni sloupce
> sloupce:
> id, nazev, poloha
> 0, bla, 25
> 0, ble, 12
> Tuhle tabulku stejne musis projit od 0. A pak
> musis odpocitat radek a na radku 25 pro sloupec.
> Mozna, ze je to vymysleno lepe.

Iterace skrz sloupce je relativně rychlá - v paměti se drží ukazatele na začátky řetězců. Jde jen o to, abyste v iteraci skrze řádky zbytečně nemapovali název sloupce na pořadí hodnoty. To je nutné vytknout z cyklu. Navíc když porovnáte časy, tak vyjma extrémně pomalých prostředí nehraje zobrazení výsledku dotazu roli - pokud se nesnažíte zobrazovat tabulku o desítkách tisíc řádků - úzké hrdlo je vlastní vykonání SQL příkazu a přesun dat po síti - případně konverze napříč různými vrstvami.

Nevím, jestli si rozumíme - trochu mi to připomělo dobu, kdy jsem začínal s SQL (ve Visual Basicu). Tehdy jsme primárně řešili jak rychle dostat data do datasetu a vůbec jsme neřešili rychlost vlastního provádění dotazu. Což je právě špatně. Ale tehdy nám to přišlo normální :)

peta1 Napsal: ------------------------------------------------------- > Pavel Stehule - Vychazim z uvahy, ze kdyz neco > programujes a prochazis pole, zacinas for > (i=0;i umisteni sloupce > sloupce: > id, nazev, poloha > 0, bla, 25 > 0, ble, 12 > Tuhle tabulku stejne musis projit od 0. A pak > musis odpocitat radek a na radku 25 pro sloupec. > Mozna, ze je to vymysleno lepe. Iterace skrz sloupce je relativně rychlá - v paměti se drží ukazatele na začátky řetězců. Jde jen o to, abyste v iteraci skrze řádky zbytečně nemapovali název sloupce na pořadí hodnoty. To je nutné vytknout z cyklu. Navíc když porovnáte časy, tak vyjma extrémně pomalých prostředí nehraje zobrazení výsledku dotazu roli - pokud se nesnažíte zobrazovat tabulku o desítkách tisíc řádků - úzké hrdlo je vlastní vykonání SQL příkazu a přesun dat po síti - případně konverze napříč různými vrstvami. Nevím, jestli si rozumíme - trochu mi to připomělo dobu, kdy jsem začínal s SQL (ve Visual Basicu). Tehdy jsme primárně řešili jak rychle dostat data do datasetu a vůbec jsme neřešili rychlost vlastního provádění dotazu. Což je právě špatně. Ale tehdy nám to přišlo normální :)

Citovat příspěvek

co vyhoda, hlavne by me zajimalo, jaky je problem i tech 250 sloupcu vyjmenovat?V oracle to umi PLSQL Developer.Udela Select , Insert s nazvama vsech sloupcu. V MSSQL to umi SQLmanagement studio, staci kliknout na tabulku pravym tlacitkem a senzma sloupcu je tu hned. Kazdopadne dostat do sesitu(excel,OOP) seznam fieldu z tabulky a vygenerovat si SELECT,UPDATE, DELETE , INSERT by snad mel umet kazdy programator, ne?

co vyhoda, hlavne by me zajimalo, jaky je problem i tech 250 sloupcu vyjmenovat?V oracle to umi PLSQL Developer.Udela Select , Insert s nazvama vsech sloupcu. V MSSQL to umi SQLmanagement studio, staci kliknout na tabulku pravym tlacitkem a senzma sloupcu je tu hned. Kazdopadne dostat do sesitu(excel,OOP) seznam fieldu z tabulky a vygenerovat si SELECT,UPDATE, DELETE , INSERT by snad mel umet kazdy programator, ne?

Citovat příspěvek

Jaká je výhoda v práci s 250 sloupcouvým select * from...?

Jaká je výhoda v práci s 250 sloupcouvým select * from...?

Citovat příspěvek

Pavel Stehule - Vychazim z uvahy, ze kdyz neco programujes a prochazis pole, zacinas for (i=0;isloupce:
id, nazev, poloha
0, bla, 25
0, ble, 12
Tuhle tabulku stejne musis projit od 0. A pak musis odpocitat radek a na radku 25 pro sloupec.
Mozna, ze je to vymysleno lepe.

Pavel Stehule - Vychazim z uvahy, ze kdyz neco programujes a prochazis pole, zacinas for (i=0;i

Citovat příspěvek

Nad Oracle si dovedu představit realizaci např. procedury:
resetcolorder ('OWNER', 'TABULKA', 'SLOUPEC1,SLOUPEC2,*')
která by zajistila, že tabulka bude začínat uvedenými sloupci, ostatní zůstanou beze změny:

- zapamatovat si granty, constrainty, indexy, triggery, commenty
- přejmenovat OWNER.TABULKA na něco dočasného
- vytvořit OWNER.TABULKA z toho dočasného s požadovaným pořadím sloupců (dle parametru a původního pořadí) - další parametry (storage, partitioning, ...) dle původní tabulky
- naplnit data z dočasné tab. (mohlo by být už o krok dřív - CREATE TABLE ... AS SELECT ... ?)
- obnovit granty, constrainty, indexy, triggery, commenty
- něco dalšího, na co jsem zapomněl
- dropnout dočasnou tabulku
- překompilovat navázané objekty

Je to hezká výzva, kdo to zrealizuje? :-)

Nad Oracle si dovedu představit realizaci např. procedury: resetcolorder ('OWNER', 'TABULKA', 'SLOUPEC1,SLOUPEC2,*') která by zajistila, že tabulka bude začínat uvedenými sloupci, ostatní zůstanou beze změny: - zapamatovat si granty, constrainty, indexy, triggery, commenty - přejmenovat OWNER.TABULKA na něco dočasného - vytvořit OWNER.TABULKA z toho dočasného s požadovaným pořadím sloupců (dle parametru a původního pořadí) - další parametry (storage, partitioning, ...) dle původní tabulky - naplnit data z dočasné tab. (mohlo by být už o krok dřív - CREATE TABLE ... AS SELECT ... ?) - obnovit granty, constrainty, indexy, triggery, commenty - něco dalšího, na co jsem zapomněl - dropnout dočasnou tabulku - překompilovat navázané objekty Je to hezká výzva, kdo to zrealizuje? :-)

Citovat příspěvek

Jinak do oraclu nevidim jestli je to nutne nebo neni, protoze je tam spoustu vrstev a vnitrnich parsovani, ze zalezi na jake urovni by mi to umoznoval nastavit. Hezka analogie je nekterych vyvojovych nastroju, kde je mozne si sloupce zprehazet a prostredi si to zapamatuje - na klasice zobrazeni dat jedne tabulky pres GUI, nikoliv na selecty z techto dat...

Takze si myslim, ze zalezi hodne na vnitrni implementaci Oracle, jestli by to nuzne vyzadovalo zmenu na urovni ulozenych dat. Urcite je tam nekde blackbox, pred prezentovanim vysledku kterej obdrzi vysledek z datové vrstvy(z pohledu ORCL) a pak to transformuje.

Jinak do oraclu nevidim jestli je to nutne nebo neni, protoze je tam spoustu vrstev a vnitrnich parsovani, ze zalezi na jake urovni by mi to umoznoval nastavit. Hezka analogie je nekterych vyvojovych nastroju, kde je mozne si sloupce zprehazet a prostredi si to zapamatuje - na klasice zobrazeni dat jedne tabulky pres GUI, nikoliv na selecty z techto dat... Takze si myslim, ze zalezi hodne na vnitrni implementaci Oracle, jestli by to nuzne vyzadovalo zmenu na urovni ulozenych dat. Urcite je tam nekde blackbox, pred prezentovanim vysledku kterej obdrzi vysledek z datové vrstvy(z pohledu ORCL) a pak to transformuje.

Citovat příspěvek

"Co takhle vytvořit z každé tabulky view (vyjmenovat sloupce) a dotazovat se na view. Při případné změně tabulek je úprava view triviální."

To znamená zdvojnásobení počtu objektu ;). Ano teoreticky to mozne je, prakticky si z kazdy xxx uzivatelu zalozi vlastni view a pak budou na DB jen a jen bordely. Staci ze tu mame par view ze stejne tabulky s trosku jinou where podminkou... a jeste to multiplikovat serazovanim sloupcu.

Tech zpusobu jak resit poradi spl, by se naslo vic. Ale alterovani by bylo vzdy to nejkrasnejsi.

"Co takhle vytvořit z každé tabulky view (vyjmenovat sloupce) a dotazovat se na view. Při případné změně tabulek je úprava view triviální." To znamená zdvojnásobení počtu objektu ;). Ano teoreticky to mozne je, prakticky si z kazdy xxx uzivatelu zalozi vlastni view a pak budou na DB jen a jen bordely. Staci ze tu mame par view ze stejne tabulky s trosku jinou where podminkou... a jeste to multiplikovat serazovanim sloupcu. Tech zpusobu jak resit poradi spl, by se naslo vic. Ale alterovani by bylo vzdy to nejkrasnejsi.

Citovat příspěvek

peta1 Napsal:
-------------------------------------------------------
> DAB "A proč jste to řešili? Proč vám vadí jiné
> pořadí sloupců?"
>
> Prvni davam nejpouzivanejsi sloupce a to jsou
> key(indexy) v poradi:
> boolean (aktivni/neaktivni clanek), cisla,
> stringy, dlouhe textove retezce
> Toto poradi by melo zajistit rychlou praci pro
> selecty a rychle vytvareni indexu, protoze vsechny
> udaje pro ne ma hned ze zacatku a nemusi
> preskakovat treba texty s promennou delkou.

Tohle je trochu zavádějící. Samozřejmě, že záleží na implementačních detailech nicméně platí, že data se čtou z disku po datových stránkách a nikoliv po řádcích, případně sloupcích. Tudíž vždy se načte jeden nebo více kompletních řádků. Úzkým hrdlem je čtení z disku - to je to co hraje primárně roli. Jak jsou pak hodnoty rozmístěné na stránce je sekundární a v podstatě to má jen minimální vliv na rychlost (při aktuálních procesorech). Něco jiného byla stará pentia nebo 486.

peta1 Napsal: ------------------------------------------------------- > DAB "A proč jste to řešili? Proč vám vadí jiné > pořadí sloupců?" > > Prvni davam nejpouzivanejsi sloupce a to jsou > key(indexy) v poradi: > boolean (aktivni/neaktivni clanek), cisla, > stringy, dlouhe textove retezce > Toto poradi by melo zajistit rychlou praci pro > selecty a rychle vytvareni indexu, protoze vsechny > udaje pro ne ma hned ze zacatku a nemusi > preskakovat treba texty s promennou delkou. Tohle je trochu zavádějící. Samozřejmě, že záleží na implementačních detailech nicméně platí, že data se čtou z disku po datových stránkách a nikoliv po řádcích, případně sloupcích. Tudíž vždy se načte jeden nebo více kompletních řádků. Úzkým hrdlem je čtení z disku - to je to co hraje primárně roli. Jak jsou pak hodnoty rozmístěné na stránce je sekundární a v podstatě to má jen minimální vliv na rychlost (při aktuálních procesorech). Něco jiného byla stará pentia nebo 486.

Citovat příspěvek

DAB "A proč jste to řešili? Proč vám vadí jiné pořadí sloupců?"

Prvni davam nejpouzivanejsi sloupce a to jsou key(indexy) v poradi:
boolean (aktivni/neaktivni clanek), cisla, stringy, dlouhe textove retezce
Toto poradi by melo zajistit rychlou praci pro selecty a rychle vytvareni indexu, protoze vsechny udaje pro ne ma hned ze zacatku a nemusi preskakovat treba texty s promennou delkou.

DAB "A proč jste to řešili? Proč vám vadí jiné pořadí sloupců?" Prvni davam nejpouzivanejsi sloupce a to jsou key(indexy) v poradi: boolean (aktivni/neaktivni clanek), cisla, stringy, dlouhe textove retezce Toto poradi by melo zajistit rychlou praci pro selecty a rychle vytvareni indexu, protoze vsechny udaje pro ne ma hned ze zacatku a nemusi preskakovat treba texty s promennou delkou.

Citovat příspěvek

lokukup Napsal:
-------------------------------------------------------
> "Ale vyplývá z toho, že změna pořadí by si
> vynutila interní přeuložení všech hodnot dané
> tabulky."
>
> To je možné a blbé

To je jiste a nutne. Kdyz se nad tim zamyslis, tak je jasny, ze bez presypani dat neni zmena struktury mozna. Schema tabulky je pro DB system navod jak ma v datovem souboru najit pozadovana data. Nemuzes mu schema zmenit a data nechat. To by si musel pamatovat nejakou historii vsech zmen struktury od zalozeni tabulky a pri kazdem pristupu jit pres tuto historii.

lokukup Napsal: ------------------------------------------------------- > "Ale vyplývá z toho, že změna pořadí by si > vynutila interní přeuložení všech hodnot dané > tabulky." > > To je možné a blbé To je jiste a nutne. Kdyz se nad tim zamyslis, tak je jasny, ze bez presypani dat neni zmena struktury mozna. Schema tabulky je pro DB system navod jak ma v datovem souboru najit pozadovana data. Nemuzes mu schema zmenit a data nechat. To by si musel pamatovat nejakou historii vsech zmen struktury od zalozeni tabulky a pri kazdem pristupu jit pres tuto historii.

Citovat příspěvek

Co takhle vytvořit z každé tabulky view (vyjmenovat sloupce) a dotazovat se na view. Při případné změně tabulek je úprava view triviální.

Co takhle vytvořit z každé tabulky view (vyjmenovat sloupce) a dotazovat se na view. Při případné změně tabulek je úprava view triviální.

Citovat příspěvek

Jinak poradi tech sloupcu je ulozeno v TB, priznam se, ze jsem teda jeste nikdy nezkusil prihlasit se jako SYS (tzn polobuh) jestli mi to necha updatovat v systemovejch tabulkach. Treba alterovat dual to kdysy (jestli ted, nevim) umoznovalo.

Jinak poradi tech sloupcu je ulozeno v TB, priznam se, ze jsem teda jeste nikdy nezkusil prihlasit se jako SYS (tzn polobuh) jestli mi to necha updatovat v systemovejch tabulkach. Treba alterovat dual to kdysy (jestli ted, nevim) umoznovalo.

Citovat příspěvek

"Ale vyplývá z toho, že změna pořadí by si vynutila interní přeuložení všech hodnot dané tabulky."

To je možné a blbé - typicky je tento požadavek kladen na velké, extrméně velké tabulky, kde neni možné/jednoduché nakliknout create table xxy as select _vyjmenovat_ from xx... a pak ji prejmenovat

"Ale vyplývá z toho, že změna pořadí by si vynutila interní přeuložení všech hodnot dané tabulky." To je možné a blbé - typicky je tento požadavek kladen na velké, extrméně velké tabulky, kde neni možné/jednoduché nakliknout create table xxy as select _vyjmenovat_ from xx... a pak ji prejmenovat

Citovat příspěvek

ok, chápu to stejně a taky by se mi to občas z těchto důvodů hodilo - ale zatím to nebylo tak urgentní, abych to řešil.
Jinak u Oracle jsou data jednotlivých sloupců uložena za sebou v daném pořadí a pokud je několik posledních sloupců rovno null, tak zabírají 0 Bytů. Přidáním not null sloupce (na konec, jinak to nejde) se tak zabere víc místa. To je ale podle mě spíš teoretický problém, byte sem, byte tam... Ale vyplývá z toho, že změna pořadí by si vynutila interní přeuložení všech hodnot dané tabulky.

ok, chápu to stejně a taky by se mi to občas z těchto důvodů hodilo - ale zatím to nebylo tak urgentní, abych to řešil. Jinak u Oracle jsou data jednotlivých sloupců uložena za sebou v daném pořadí a pokud je několik posledních sloupců rovno null, tak zabírají 0 Bytů. Přidáním not null sloupce (na konec, jinak to nejde) se tak zabere víc místa. To je ale podle mě spíš teoretický problém, byte sem, byte tam... Ale vyplývá z toho, že změna pořadí by si vynutila interní přeuložení všech hodnot dané tabulky.

Citovat příspěvek

vadí, spouštíme tam analyticke selecty na objenávky (ELT) a jde neco mezi analyzou a programovanim - tzn scripty a selecty jsou pousteny a psany z ruky - a poradi sloupcu vadi z praktickejch duvodu a rychlosti.

Klidne muzu souhlasit, ze to jde v pohode (a je to krasnejsi i principalne lepsi) vyjmenovat a urcit si poradi jak chci. Ale v pripade, kdy pisu do TOAD/SQL Developer destiky selectu a scriptu v ruce tak je mi to pochopitelne neprijemne. Select * je na psani rychlejsi, zvlast kdyz potrebuji "nejakej" vysledek, kterej nejspise jednou vyjedu, pouziju si nejake ID objednavek a uz nikdy nespustim.

Jinak priklad: vzniknul externi system, ID do tohot systemu (cizi klic, unikatni) jsme alertovali na konec tabulky a ted musime v TOADU/SQL developeru to hledat nekde na konci...

Jinak mame tam tabulky, ktere maji 230 sloupcu - casem se nejake zmeni, nejake pribudou a pak ty nejdulezitejsi jsou treba u prostred.

Dalsi vec je, ze kdyz si je seradite po nejakem case jak chcete, nemusite si pamatovat jak se ten sloupec jmenuje (na to aby jste si vyselectili jen ten), nemusite ho hledat.

Tedy proc? K urychleni prace ve specifickem typu prace ve kterem pracujeme, k zprijemneni prace atd. Nema to nic spolecneho z daty, jde o cas a pohodli.

Kdyz nejake jelito vytvari tabulku a da jeden z nejduletizejsich a nejpouzivanejsich (a nebo to v te dobe neni zname/ocekvane) na 55 pozici... tak pri analyticke praci, kdy se reporty/analyzy/testy/vysledky... pisou primo ve vyvojovem prostedi "z ruky" tak to je na facku :D

vadí, spouštíme tam analyticke selecty na objenávky (ELT) a jde neco mezi analyzou a programovanim - tzn scripty a selecty jsou pousteny a psany z ruky - a poradi sloupcu vadi z praktickejch duvodu a rychlosti. Klidne muzu souhlasit, ze to jde v pohode (a je to krasnejsi i principalne lepsi) vyjmenovat a urcit si poradi jak chci. Ale v pripade, kdy pisu do TOAD/SQL Developer destiky selectu a scriptu v ruce tak je mi to pochopitelne neprijemne. Select * je na psani rychlejsi, zvlast kdyz potrebuji "nejakej" vysledek, kterej nejspise jednou vyjedu, pouziju si nejake ID objednavek a uz nikdy nespustim. Jinak priklad: vzniknul externi system, ID do tohot systemu (cizi klic, unikatni) jsme alertovali na konec tabulky a ted musime v TOADU/SQL developeru to hledat nekde na konci... Jinak mame tam tabulky, ktere maji 230 sloupcu - casem se nejake zmeni, nejake pribudou a pak ty nejdulezitejsi jsou treba u prostred. Dalsi vec je, ze kdyz si je seradite po nejakem case jak chcete, nemusite si pamatovat jak se ten sloupec jmenuje (na to aby jste si vyselectili jen ten), nemusite ho hledat. Tedy proc? K urychleni prace ve specifickem typu prace ve kterem pracujeme, k zprijemneni prace atd. Nema to nic spolecneho z daty, jde o cas a pohodli. Kdyz nejake jelito vytvari tabulku a da jeden z nejduletizejsich a nejpouzivanejsich (a nebo to v te dobe neni zname/ocekvane) na 55 pozici... tak pri analyticke praci, kdy se reporty/analyzy/testy/vysledky... pisou primo ve vyvojovem prostedi "z ruky" tak to je na facku :D

Citovat příspěvek

lokukup Napsal:
> Dost jsme to resili a prave jsem otevrel tento
> thread, jestli se tu nenaskytne nahodou odpoved

A proč jste to řešili? Proč vám vadí jiné pořadí sloupců?

lokukup Napsal: > Dost jsme to resili a prave jsem otevrel tento > thread, jestli se tu nenaskytne nahodou odpoved A proč jste to řešili? Proč vám vadí jiné pořadí sloupců?

Citovat příspěvek

lokukup Napsal:
-------------------------------------------------------
> Ahoj, muzu parazitovat na tomto threadu a zeptat
> se jestli to jde/umi nekdo/jak jde v Oracle? Diky
>
>
> Dost jsme to resili a prave jsem otevrel tento
> thread, jestli se tu nenaskytne nahodou odpoved

Žádný jednoduchý ALTER na toto neexistuje - aneb jedině vytvořit tabulku znovu.
K tomu se dá třeba využít dbms_metadata, snad i dbms_redefinition.

lokukup Napsal: ------------------------------------------------------- > Ahoj, muzu parazitovat na tomto threadu a zeptat > se jestli to jde/umi nekdo/jak jde v Oracle? Diky > > > Dost jsme to resili a prave jsem otevrel tento > thread, jestli se tu nenaskytne nahodou odpoved Žádný jednoduchý ALTER na toto neexistuje - aneb jedině vytvořit tabulku znovu. K tomu se dá třeba využít dbms_metadata, snad i dbms_redefinition.

Citovat příspěvek

Ahoj, muzu parazitovat na tomto threadu a zeptat se jestli to jde/umi nekdo/jak jde v Oracle? Diky

Dost jsme to resili a prave jsem otevrel tento thread, jestli se tu nenaskytne nahodou odpoved

Ahoj, muzu parazitovat na tomto threadu a zeptat se jestli to jde/umi nekdo/jak jde v Oracle? Diky Dost jsme to resili a prave jsem otevrel tento thread, jestli se tu nenaskytne nahodou odpoved

Citovat příspěvek

Zorro Napsal:
-------------------------------------------------------
> Potřebuju to v MS SQL 2000. Tam to funguje? Když
> jo, tak jak?

nejde. Muzes to udelat pres management studio (u mssql 2k enterprise manager), ale to interne dela akorat to, ze udela novou tabulku s pozadovanymi zmenami, prelije do ni stara data a starou tabulku smaze. Pokud tam nemas moc dat, tak s tim ale problem nebude.

Zorro Napsal: ------------------------------------------------------- > Potřebuju to v MS SQL 2000. Tam to funguje? Když > jo, tak jak? nejde. Muzes to udelat pres management studio (u mssql 2k enterprise manager), ale to interne dela akorat to, ze udela novou tabulku s pozadovanymi zmenami, prelije do ni stara data a starou tabulku smaze. Pokud tam nemas moc dat, tak s tim ale problem nebude.

Citovat příspěvek

Potřebuju to v MS SQL 2000. Tam to funguje? Když jo, tak jak?

Potřebuju to v MS SQL 2000. Tam to funguje? Když jo, tak jak?

Citovat příspěvek

2010/8/16 Zorro :
> Zdravím všechny.
> Mám dotaz. Dá se v tabulce měnit pořadí sloupců? Mám např. 4 sloupce (ID, jmeno, prijmeni, datum_nar) a chci pridat sloupec NARODNOST a to tak, že bude v tabulce mezi prijmenim a datem narozeni. Samozrejme vim, ze by se to dalo upravit ve výsledném SELECTU nebo v pohledu, ale chtěl bych to mít pěkné hned v tabulce. Nebo bych si tu tabulku musel zase celou nadefinovat znovu (už se správným pořadím sloupců)? Díky moc

Nektere DB to umi, nektere ne. Ty samozrejme nepises jakou DB
pouzivas, takze si vyberu (treba ;)) Firebird a ten to umi.

Ale spravne by ti melo byt poradi sloupcu jedno, tj. nemel bys na tom
stavet nejake predpoklady.

--
Jiri {x2} Cincura (x2develop.com founder)
http://blog.cincura.net/ | http://www.ID3renamer.com

Příspěvek zaslán emailem

2010/8/16 Zorro : > Zdravím všechny. > Mám dotaz. Dá se v tabulce měnit pořadí sloupců? Mám např. 4 sloupce (ID, jmeno, prijmeni, datum_nar) a chci pridat sloupec NARODNOST a to tak, že bude v tabulce mezi prijmenim a datem narozeni. Samozrejme vim, ze by se to dalo upravit ve výsledném SELECTU nebo v pohledu, ale chtěl bych to mít pěkné hned v tabulce. Nebo bych si tu tabulku musel zase celou nadefinovat znovu (už se správným pořadím sloupců)? Díky moc Nektere DB to umi, nektere ne. Ty samozrejme nepises jakou DB pouzivas, takze si vyberu (treba ;)) Firebird a ten to umi. Ale spravne by ti melo byt poradi sloupcu jedno, tj. nemel bys na tom stavet nejake predpoklady. -- Jiri {x2} Cincura (x2develop.com founder) http://blog.cincura.net/ | http://www.ID3renamer.com Příspěvek zaslán emailem

Citovat příspěvek

A prezradíš DB?

A prezradíš DB?

Citovat příspěvek