Autor Téma: Otázky začínajúceho  (Přečteno 10220 krát)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Otázky začínajúceho
« kdy: 02-10-2012, 11:00:54 »
Inštaloval som si FB 2.5

1) Type
Chýba mi

a) Memo
vrachar() asi nebude to pravé. Nedá sa použiť Enter a vytvorenie odsekov. Ostáva BLOB a ten sa mi javí ako kanón na vrabce. Samozrejme chcem využívať TMemo na formulároch a aj v tlačových zostavách. Mám na mysli ich automatické zalamovanie textu a v prípade zostáv aj prispôsobenie výšky obsahu.

b) Boolean
Nadefinoval som si (vzhľadom na vlastné zvyky)|
Char(5)
Check (Value = ‘True‘ or Value = ‘False‘)
NUll – False (nemusí sa zadať. Niekedy potrebujem tri stavy)
Je to dobre? Viem, že vnútorne je Boolean reprezentovaný celými číslami.

2) Použitie
a) Numeric
Nadefinoval som Numeric(8, 0) pre zadávanie IČO. V štyroch záznamoch som mal tri rôzne dĺžky (zapisoval som vždy maximálny počet číslic, ktorý mi to umožnilo) a to 11, 9 a 7. Nerozumiem prečo. Podľa mňa by tam malo byť vždy 8 číslic.

b) Char() – VarChar() Úvaha
Char() má podľa význam používať v prípadoch keď je presne daný počet/max počet znakov. Napr. PSČ, IČO. Ináč Varchar().
Je tam niečo, čo túto úvahu neguje?

3) Domain
Tie sa mi veľmi páčia. Ale predpokladám, že majú význam len tam, kde sa v budúcnosti môže niečo zmeniť. Definovať Domain pre napr. Char(5), VarChar(10), VarChar(20) a podobne (čiže základné typy bez ďalšieho upresnenia) nemá zmysel.

4) Pripojenie k DB v D XE2
To sa mi nepodarilo. Stiahol som si ZEOS, ale tam bola podpora len do D2010. Možno existuje niečo novšie. Prosím, čo mi odporúčate, aby som mohol využiť všetky možnosti, ktoré FB núka. Poznám len Access a je to už na prvý pohľad značný rozdiel.

Vytvoril som DB (hurá) a na moje prekvapenie tam nevidím žiadne rozšírenie, len samotný názov DB. Má to tak byť?
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1559
  • Karma: 37
    • Pepak.net
Re:Otázky začínajúceho
« Odpověď #1 kdy: 02-10-2012, 11:42:55 »
a) Memo
vrachar() asi nebude to pravé. Nedá sa použiť Enter a vytvorenie odsekov.
Klidně můžeš použív VARCHAR. Samozřejmě do něj jde vložit jakýkoliv znak, včetně ENTERu.

Citace
Ostáva BLOB a ten sa mi javí ako kanón na vrabce.
Proč kanón na vrabce? BLOB je datový typ určený pro ukládání velkých dat, ve kterých se nebude hledat. Jestli to jsou textová data nebo grafická data je celkem jedno (dokonce, BLOB SUBTYPE 0 je definován jako textový).

Citace
Samozrejme chcem využívať TMemo na formulároch a aj v tlačových zostavách. Mám na mysli ich automatické zalamovanie textu a v prípade zostáv aj prispôsobenie výšky obsahu.
Nic z toho není závislé na tom, jestli použiješ VARCHAR nebo BLOB.

Citace
b) Boolean
Nadefinoval som si (vzhľadom na vlastné zvyky)|
Char(5)
Check (Value = ‘True‘ or Value = ‘False‘)
NUll – False (nemusí sa zadať. Niekedy potrebujem tri stavy)
Je to dobre? Viem, že vnútorne je Boolean reprezentovaný celými číslami.
"Dobře" je ošemetné slovo. Je to možné udělat i takhle, zvlášť když to nadefinuješ jako doménu a v ní uděláš omezení jen na hodnoty "True" a "False". Obvyklejší je ale použít buď nějaký malý INT (nula, jedna, NULL), u kterého se ti budou snadno dělat konverze z/na Delphovský boolean, nebo CHAR(1) (např. "Y", "N", NULL, nebo "A", "N", NULL, nebo klidně i "1", "0", NULL).

Citace
2) Použitie
a) Numeric
Nadefinoval som Numeric(8, 0) pre zadávanie IČO. V štyroch záznamoch som mal tri rôzne dĺžky (zapisoval som vždy maximálny počet číslic, ktorý mi to umožnilo) a to 11, 9 a 7. Nerozumiem prečo. Podľa mňa by tam malo byť vždy 8 číslic.
Možná se pletu, ale řekl bych, že Firebird reprezentuje NUMERIC jako číslo v plovoucí desetinné čárce. Pokud chceš BCD, tak je na to DECIMAL.

Každopádně pro IČO bych nepoužil ani jedno z toho, ale VARCHAR, a to délky tak asi 20.

Citace
b) Char() – VarChar() Úvaha
Char() má podľa význam používať v prípadoch keď je presne daný počet/max počet znakov. Napr. PSČ, IČO. Ináč Varchar().
Je tam niečo, čo túto úvahu neguje?
Tak například to, že PSČ nemá pevný počet znaků. IČO taky ne (jsou i "krátká IČa").
Moje zkušenost je taková, že CHAR má smysl pouze pro případ CHAR(1), a to ještě ne vždy. Jinak používat VARCHAR.

Citace
3) Domain
Tie sa mi veľmi páčia. Ale predpokladám, že majú význam len tam, kde sa v budúcnosti môže niečo zmeniť. Definovať Domain pre napr. Char(5), VarChar(10), VarChar(20) a podobne (čiže základné typy bez ďalšieho upresnenia) nemá zmysel.
Ano, "bez dalšího upřesnění". Jenže na domain můžeš udělat i upřesnění, jako třeba "smí obsahovat pouze hodnoty od 100 do 200" nebo "musí začínat nebo končit na A".

Citace
Vytvoril som DB (hurá) a na moje prekvapenie tam nevidím žiadne rozšírenie, len samotný názov DB. Má to tak byť?
Databáze se jmenuje tak, jak si ji pojmenuješ. Firebirdu je to úplně jedno, klidně bude pracovat s databází pojmenovanou format.exe.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #2 kdy: 02-10-2012, 12:07:21 »
//Klidně můžeš použív VARCHAR. Samozřejmě do něj jde vložit jakýkoliv znak, včetně ENTERu.
To som zvedavý, lebo Access + TDBEdit enter nebral.

//Obvyklejší je ale použít buď nějaký malý INT (nula, jedna, NULL), u kterého se ti budou snadno dělat konverze z/na Delphovský boolean,
Hm, to mohlo fungovať aj v SQL. Len teraz nechápem ako to zrealizovať. Nie že mi hneď odpovieš :)

//Pokud chceš BCD, tak je na to DECIMAL.
Asi som si to poplietol

//Databáze se jmenuje tak, jak si ji pojmenuješ.
Už som to zistil
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1559
  • Karma: 37
    • Pepak.net
Re:Otázky začínajúceho
« Odpověď #3 kdy: 02-10-2012, 12:19:27 »
//Klidně můžeš použív VARCHAR. Samozřejmě do něj jde vložit jakýkoliv znak, včetně ENTERu.
To som zvedavý, lebo Access + TDBEdit enter nebral.
To je ale limit TDBEditu, nikoliv podkladové databáze. (No, Accessu, možná jo, kdo ví...)

Citace
//Obvyklejší je ale použít buď nějaký malý INT (nula, jedna, NULL), u kterého se ti budou snadno dělat konverze z/na Delphovský boolean,
Hm, to mohlo fungovať aj v SQL. Len teraz nechápem ako to zrealizovať. Nie že mi hneď odpovieš :)
Třeba INTEGER, když nad tím nechceš přemýšlet...

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #4 kdy: 02-10-2012, 12:35:41 »
Práveže som chcel. O Integer samozrejme viem.
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 576
  • Karma: 25
Re:Otázky začínajúceho
« Odpověď #5 kdy: 02-10-2012, 12:36:34 »
ad Numeric - třeba v MSSQL to bylo uložené ve fixed point. Floating point je lepší moc nepoužívat (já jsem to nepotřeboval snad ještě nikdy)

ad PSČ, IČO, telefony atd - toto by mělo být uloženo jako string. Sice to mívá v názvu číslo, ale prakticky se s tím stejně pracuje jako s textem (třeba sčítat nebo násobit PSČ nemá žádný smysl). Čistě teoreticky není důvod, proč by IČO nebo PSČ nemohly obsahovat i písmena, to je jenom historický zvyk. U některých zahraničních adres obdoba PSČ obsahuje i písmena.

ad char, varchar - první má pevně daný počet znaků a pokud tam uložíš kratší text, tak ho doplní mezerama (alespoň tak to dělá MSSQL). Takže se rozhodni, jestli ti to vadí nebo ne - na ukládání vždy stejně dlouhých textů to použít jde, na různě dlouhé texty je většinou lepší varchar.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #6 kdy: 02-10-2012, 13:24:05 »
Takže pripojenie by malo ísť pomocou ZeosDBO 7.0. Je to staršieho dátumu, keď dxe2 ešte nebolo. V package je posledné Delphi14.

Bude to fungovať? Má to niekto odskúšané?

//ad PSČ, IČO, telefony
Riešim to pomocou Char. Čísla by len robili problém. Už len napr. to formátovať. Bolo to uvedené ako príklad.
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #7 kdy: 02-10-2012, 13:47:11 »
ad PSČ, IČO, telefony atd - toto by mělo být uloženo jako string. Sice to mívá v názvu číslo, ale prakticky se s tím stejně pracuje jako s textem (třeba sčítat nebo násobit PSČ nemá žádný smysl). Čistě teoreticky není důvod, proč by IČO nebo PSČ nemohly obsahovat i písmena, to je jenom historický zvyk. U některých zahraničních adres obdoba PSČ obsahuje i písmena.
Presne. Nic co neni cislo urcene pro matematicke operace jako cislo do DB neukladat, ale jako text. Napr. ja mam u chalupy c.p. '02' a divili byste se, kolik softu to neumoznuje v adrese zadat a leze jim z toho '2', coz je uplne jiny objekt, protoze tou nulou se rozlisuji rekreacni objekty od objektu k trvalemu bydleni.


ad char, varchar - první má pevně daný počet znaků a pokud tam uložíš kratší text, tak ho doplní mezerama (alespoň tak to dělá MSSQL). Takže se rozhodni, jestli ti to vadí nebo ne - na ukládání vždy stejně dlouhých textů to použít jde, na různě dlouhé texty je většinou lepší varchar.
Ja bych char pouzival jen tam, kde je velikost dana nejakou normou napr. kod statu, kod meny, apod. s tim, ze pokud to DB umi, definoval bych to jako domainu
napr.
Kód: SQL [Vybrat]
  1. CREATE DOMAIN D_LANGUAGECODE AS CHAR(2);    -- see  ISO 639-2
  2.  
a kdyby se nekdy pozdeji ukazalo, ze se prejde treba na ISO 639-3, tak bych zmenil jen tuhle definici.

Z toho plyne, ze nesouhlasim s čiže základné typy bez ďalšieho upresnenia. Pokud nemam omezujici podminky pro SQL, ze musi byt prenositelny na jiny DB stroj, tak ma smysl pouzivat je vzdy a vsude a na nativni typy zapomenout (tak to opravdu s ptakem ohnivakem delame), protoze situaci, kdy se pri delsim zivostnim cyklu neco zmeni jen hafo (ne nadarmo se traduje, ze konstanta konstant je promenna) a opravovat rucne desitky tabulek je ptakovina, kdyz existuje prostredek, jak se tomu vyhnout.  Smyslem je definovat si logicke pojmy jako cena, dph, teplota, mena atd... a na jedinem miste jim priradit fyzickou reprezentaci, kterou lze pozdeji snadno zmenit pro celou DB.

Ostatne to neplati jen pro DB, takhle by se mel psat kazdy soft, ktery musi zit delsi dobu a ma byt snadno udrzovatelny a taky se tak slusne softy pisou.



Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #8 kdy: 02-10-2012, 14:12:09 »
Ktorú znakovú sadu mám nastaviť pre slovenčinu? Žeby utf8?
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #9 kdy: 02-10-2012, 14:26:27 »
Ktorú znakovú sadu mám nastaviť pre slovenčinu? Žeby utf8?
My pouzivame WIN1250, s UTF8 zkusenosti nemam.

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 576
  • Karma: 25
Re:Otázky začínajúceho
« Odpověď #10 kdy: 02-10-2012, 16:35:30 »
My pouzivame WIN1250, s UTF8 zkusenosti nemam.

Kde to jde bych dneska dával unicode (třeba to utf-8), pak nehrozí, že bude člověk potřeba uložit nějaké cizí znaky a vylezou z toho čtverečky nebo otazníky.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #11 kdy: 02-10-2012, 16:39:35 »
Kde to jde bych dneska dával unicode (třeba to utf-8), pak nehrozí, že bude člověk potřeba uložit nějaké cizí znaky a vylezou z toho čtverečky nebo otazníky.
Souhlasim, jen tohle s ptakem ohnivakem se vlece z historie

Offline KarelHorky

  • Plnoletý
  • ***
  • Příspěvků: 238
  • Karma: 9
    • Verze Delphi: XE6, Delphi 10.2 Tokyo
Re:Otázky začínajúceho
« Odpověď #12 kdy: 04-10-2012, 08:28:14 »
3) Domain
Tie sa mi veľmi páčia. Ale predpokladám, že majú význam len tam, kde sa v budúcnosti môže niečo zmeniť. Definovať Domain pre napr. Char(5), VarChar(10), VarChar(20) a podobne (čiže základné typy bez ďalšieho upresnenia) nemá zmysel.

Definovat doménu pro každý sloupec v tabulce se vyplatí vždy, protože když se definuje tabulka bez domén, tak Firebird si pro KAŽDÝ sloupec v této tabulce interně stejně doménu vytvoří. Pak je interní tabulka s popisem sloupců zaplněna obrovským množstvím jednoduchých domén. Při jakékoliv práci se pak DB engine musí touto obří tabulkou prodírat.
Domény pro Varchar si definuj vždy včetně určení Charset a Collate, případně Not Null, pak na to nikdy nezapomeneš a nespleteš se. Navíc, pokud jednou povolíš ve sloupci hodnotu Null, už to později nejde nijak změnit, jen založením nového sloupce.

Win10 Prof 64b, Firebird 2.5

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #13 kdy: 04-10-2012, 08:36:39 »
Pekne napísané, takže sa k tomu vrátim.

// Navíc, pokud jednou povolíš ve sloupci hodnotu Null,
Na základe nejakých textov to riešim v aplikácii. Takže do DB "vždy" posielam správne údaje.
Bolo to zdôvodnené tým, že v aplikácii s tým nie je žiaden problém. Ani do budúcna. Kdežto, ak to je v DB, tak sa najprv musí zistiť o akú chybu ide a potom reagovať.

V "mojom" Accesse som teda nevedel (a nielen ja) zistiť návratový kód chyby. Tak sa to v mnohých prípadoch nedalo ošetriť.

// Navíc, pokud jednou povolíš ve sloupci hodnotu Null, už to později nejde nijak změnit,
V IBExpres to ide. Bolo nad prázdnou tabuľkou.
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #14 kdy: 04-10-2012, 08:59:23 »
Domény pro Varchar si definuj vždy včetně určení Charset a Collate, případně Not Null, pak na to nikdy nezapomeneš a nespleteš se. Navíc, pokud jednou povolíš ve sloupci hodnotu Null, už to později nejde nijak změnit, jen založením nového sloupce.
Souhlasim s pouzivanim domain vsude, takze jen technicka poznamka k moznosti-nemoznosti: rekl bych, ze IB Expert bez problemu prida NOT NULL constraint, jen bude chtit zadat default hodnotu a budes si muset rucne napsat evolucni script, ktery zajisti, ze u vsech existujicich zaznamu nacpe nejakou default hodnotu.
« Poslední změna: 04-10-2012, 09:04:46 od pf1957 »

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #15 kdy: 04-10-2012, 09:04:18 »
Na základe nejakých textov to riešim v aplikácii. Takže do DB "vždy" posielam správne údaje.
Database by mela byt mimo transakci v kterykoli okamzik logicky konzistenti a s neporusenou integritou. Takze se nikdy nespoleha na to, ze to zajisti klient, ale dela se to deklarativne temi CHECKS u domain a proceduralne v triggerech ev. u slozitejsich zmen v SP, kde se bud dosadi neco default, kdyz to jde nebo se raisne exception.

Offline KarelHorky

  • Plnoletý
  • ***
  • Příspěvků: 238
  • Karma: 9
    • Verze Delphi: XE6, Delphi 10.2 Tokyo
Re:Otázky začínajúceho
« Odpověď #16 kdy: 04-10-2012, 09:13:07 »
// Navíc, pokud jednou povolíš ve sloupci hodnotu Null, už to později nejde nijak změnit,
V IBExpres to ide. Bolo nad prázdnou tabuľkou.
Zkus to s naplněnou tabulkou. Několik sloupců, jeden nebo víc s povolením Null, pár záznamů. Potom zkus změnit definice na Not Null. Jde to udělat jen přes nový sloupec, zkopírováním původního obsahu, dropnutím původního a přejmenovaním nového.
Kouzelníci v IBExpertu to možná také tak udělají  :)
Win10 Prof 64b, Firebird 2.5

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #17 kdy: 04-10-2012, 09:22:55 »
Zkus to s naplněnou tabulkou. Několik sloupců, jeden nebo víc s povolením Null, pár záznamů. Potom zkus změnit definice na Not Null. Jde to udělat jen přes nový sloupec, zkopírováním původního obsahu, dropnutím původního a přejmenovaním nového.
Kouzelníci v IBExpertu to možná také tak udělají  :)
Jasne ze s naplnenou. Ale u firebirdu jsem to rucne nikdy nezkousel, vsechno delame pres IBE. Ted me napada, kdyz to delas rucne, tak ti pujde zmenit domaina za jinou, ktera bude mit not null constraint? Z IBE to jde taky bez problemu.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6146
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Otázky začínajúceho
« Odpověď #18 kdy: 04-10-2012, 09:26:35 »
Na základe nejakých textov to riešim v aplikácii. Takže do DB "vždy" posielam správne údaje.
Database by mela byt mimo transakci v kterykoli okamzik logicky konzistenti a s neporusenou integritou. Takze se nikdy nespoleha na to, ze to zajisti klient, ale dela se to deklarativne temi CHECKS u domain a proceduralne v triggerech ev. u slozitejsich zmen v SP, kde se bud dosadi neco default, kdyz to jde nebo se raisne exception.

Tak to bude veľmi ťažký boj. Ale už keď som kúpil ten IBExpert  :'(
W10 64b, Delphi 10.4, FireBird 3.08
Expert na kladenie nejasne formulovaných otázok.

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 576
  • Karma: 25
Re:Otázky začínajúceho
« Odpověď #19 kdy: 04-10-2012, 18:47:04 »
Jasne ze s naplnenou. Ale u firebirdu jsem to rucne nikdy nezkousel, vsechno delame pres IBE. Ted me napada, kdyz to delas rucne, tak ti pujde zmenit domaina za jinou, ktera bude mit not null constraint? Z IBE to jde taky bez problemu.

řada věcí ale jedním dotazem udělat nejde. Třeba u MSSQL jde taky hromada věcí naklikat v management studiu (třeba přejmenování sloupců nebo změna pořadí), ale interně to dělají tak, že vyrobí novou tabulku se změněnou strukturou, data do ní přelijí, smažou původní a novou přejmenují na původní název. Takže z pohledu uživatele to vypadá, že to jde.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #20 kdy: 04-10-2012, 19:00:32 »
ale interně to dělají tak, že vyrobí novou tabulku se změněnou strukturou, data do ní přelijí, smažou původní a novou přejmenují na původní název. Takže z pohledu uživatele to vypadá, že to jde.
To je jasny. Ale nekomu, kdo evoluje DB schema je to prece uplne jedno, hlavne kdyz to nemusi delat pesky a nekdo to za nej udela.

Jedno to prestava byt, kdyz se pustis do vyvoje nejakeho takoveho evolucniho nastroje. Ja se kdysi snazil evoluvat v jednom OSS projektu ORM engine pro MySQL stejne, jako jim to fungovalo s Postgre a jeste ted se mi z toho dela spatne, kdyz si vzpomenu, jak tam skoro nic neslo, protoze referenci integritu k InnoDB nekdo nejak dodatecne prilepil...

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 576
  • Karma: 25
Re:Otázky začínajúceho
« Odpověď #21 kdy: 05-10-2012, 09:20:39 »
To je jasny. Ale nekomu, kdo evoluje DB schema je to prece uplne jedno, hlavne kdyz to nemusi delat pesky a nekdo to za nej udela.

Jedno to prestava byt, kdyz se pustis do vyvoje nejakeho takoveho evolucniho nastroje. Ja se kdysi snazil evoluvat v jednom OSS projektu ORM engine pro MySQL stejne, jako jim to fungovalo s Postgre a jeste ted se mi z toho dela spatne, kdyz si vzpomenu, jak tam skoro nic neslo, protoze referenci integritu k InnoDB nekdo nejak dodatecne prilepil...

Ono to vždycky jedno není. Je rozdíl, jestli nějakou změnu zvládne udělat db engine hned (protože přejmenování tabulky je jenom změna řádku v nějaké systémové tabulce) nebo se to musí dělat nějakým hackem a kopírovat na pozadí kvanta dat. Taky už se mi u větších tabulek stalo, že se změna prováděla minutu, pak vypršel timeout na dotaz a celé se to zrušilo rollbackem.

A MySQL není databáze, to bych sem vůbec netahal :-).

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3338
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Otázky začínajúceho
« Odpověď #22 kdy: 05-10-2012, 09:31:13 »
Ono to vždycky jedno není. Je rozdíl, jestli nějakou změnu zvládne udělat db engine hned (protože přejmenování tabulky je jenom změna řádku v nějaké systémové tabulce) nebo se to musí dělat nějakým hackem a kopírovat na pozadí kvanta dat.
Mas pravdu, neni samozrejme nad poradny navrh na zacatku. Ja tu zrovna resim nejake hnusne zmeny v DB a kdyz spoustim evolucni scripty, ktere ze starych dat dopocitavaji nejake nove hodnoty a prepocitavaji prubezne vyhodnovane hodnoty nad plnou databazi, tak mam dva, ktery kazdy trva asi 5 hodin :-( A navic to vypada, ze mam nekde chybu, protoze to vypocetlo kraviny  :'(