PHP OOP verzus transakce

mytrix:to protoze objednavky jsou blby prikald, ktery jsem jen orzvedl. tam vetsinou je relace 1:N, ale pokud mas tabulku s relaci 1:1-N pak uz problem masmartinzsa:ja nic neresim, odpoved mam od Bata :o) Btw. mam za sebou skoro 7letou praxi v PHP s objekty,ale o to tu nejde. ja se ptam na best practic. Pokud mas potrebu zavadet sem osobni utoky, nemusis prispivat, nenutim Te. jak jsem psal na zacatku, snazim se jen poukaz na moznou nekompatibilutu objektu a objektu v dtb.zkusim tedy naposled:mas formular ve kterem je input jmeno, prijmeni, zamestnani - vychazejme z toho, ze programujeme neco pro firmu, tedy nezamestnany clovek nemuze existovat (relace 1:1-N) spravne to tedy mas mit v DB tak, ze mas 3! tabulky. zamestnanec, zamestnani a provazani zamestnanec a zamestnani (porad mysli na to, ze programujes obrovskou aplikaci, takze nejake pole je nesmysl - uz jen tam resit duplicity). Pokud formular odesles a chces zalozit rovnou zamestnance a zamestnani dostanes se do paradoxu, ze pokud jedno selze budes mit v tabulce zamestnani prvek, ktery vznikl spolecne se zamestancem,a le ten se neulozil, tedy je nadbytecny a nema se jak provest ulozeni v tabulce s provazanim. ted by jsi mel sparvne smazat zamestnani, protoze jej nemas jak pouzit a to je zase zbytecna rezie navic a musis resit co se stane, kdyz se nepodari mazani, atd.pouzil jsi nekdy transakce? pokud ano, vedel by si o cem mluvim. Bat mne jenom nakopnul, ze muzu s transakci operovat i v aplikacni logice

No jasny, ale tak v tom pripade je tabulka "Zamestnani" pouhym ciselnikem. Tzn ty data si zijou sama o sobe bez navaznosti, respektive je tam vazba M:N (kde M <0;nekonecno> a N<1;nekonecno>)Takze zustavaji dve tabulky Zamestnanci a ZamestnaniZamestnancu. Pri ukladani noveho zaznamu nejdrive ukladas Zamestnani do ciselniku a pak teprve ukladas Zamestnance a nasledne jeho zamestnani.Situace, ze by se Zamestnani neulozilo/neexistovalo jiz drive je hodne mala. Pokud prece, nedojde ani k ulozeni Zamestnance a jeho zamestnani protoze odkaz by neexistoval. (to si uz hlida relace db)

mytrix:super, konecne se chapeme. To Tvoje reseni je pravda, ale jen do doby kdy jeden bez druheho nemuze existovat, tedy nema smysl aby zamestnani existovalo bez toho, ze alespon jeden zamestnanec jej vyuziva. jak sam pise, sance tam mala sice je, ale je - to co ted napr. pisu je aplikace s ragistarci CNB, tam si nemuzu dovolit ani malou chybu. Takze to prave vyresim pres transakcejeste pro martinsza:neber to jako utok, jen tu teoretizujeme, precti si neco o normalnich formach navrhu databaze. resi prave duplicity(redudanci) databaze, pak uvidis proc mi vadi to Tvoje reseni a nemuzu ho u tak zatezovane aplikace pouzit.Hezky je to popsano treba tady http://www.biexperts.cz/index.php/cs/component/content/article/18-ctsql/31-arnormalization.html

No "setreni" v tomto pripade moc smyslu nema. Ciselnik je jednou ceselnikem a pocet jeho polozek je omezeny. Kolik tech povolani muze existovat? tisice, max desitka tisic? Pro db je absolutne zanedbatelna polozka a nic tim neziskas. Resit toto si ty problemy zbytecne pridelavas. Navic pokud neexistuje definovany cislenik predem, dostavas se do problemu, ze ti uzivatele budou zadavat duplicitni udaje. Jednou zadá "stavař" pak "stavar" pritom je to to stejne nehlede na rozdilnost v zapisu pismen, mezer, preklepu atd. Tim ti nasledne vznikaji dalsi problemy s nejednoznacnosti zaznamu (aneb kolik zamestnancu ma povolani "stavar" nebo "stavař" nebo ..?) Takze stejne ten standardizovany ciselnik potrebujes.Jo pokud bys trval na tiom, ze to chces proste cistit, tak neni nic jednodussiho, nez jednou za cas pustit jednoduchej SQL dotaz, ktery Zamestnani procisti od neexistujicich relaci. Ale resit to primo u ukladani objektu v ramci logiky je zbytecna starost navic a hlavne to nejak "elegantne" resit ani nelze. Kazdopadne nedela se to a nikdy jsem se s tim nesetkal. :)

stale nechapem o co ti ide...zacnem transakciu, dotazem sa na db ci mi dany zamestanec existuje, to iste so zamestnanim, co neexistuje dohodim do db, ak vse preslo commit db ak nie rollback...

(porad mysli na to, ze programujes obrovskou aplikaci, takze nejake pole je nesmysl - uz jen tam resit duplicity)

pole nezmysel neni lebo neni na db urovni ale na aplikacnej a zabezpecuje relaciu medzi objektami, a duplicity riesit nemusim kedze pomocou kompozitneho primarneho kluca mi duplicity vznikat nemozu...

mytrix:jasne, v tomhle mas pravdu, ja pouzil zamestnani pro priklad, ve skutecnosti to muzou byt napriklad cisla registrace u CNB a tam uz duplicita problem je a da se snadno odhalit, cislo registrace ma jasne definovany tvarmartinsza:jenze o transakci mluvis az ted, stejne tak rikas, ze je to na urovni aplikacni vrstvy, ale na navrhu DB to mas stejne (alespon predpokladam, ze je Customer.Orders je pole, jinak by jsi musel pro kazdou objednavku zalozit noveho zakaznika.Pokud by jsi to chtel resit unikatnim klicem, musel bys mit vzdy jednu objednavku v jednom sloupci a duplikovat customera.Tak jak sji to navrhly Ty, by tedy bylo:Order1 1 "hracka" 17.6.20112 1 "teniska" 17.6.2011Customer1 "Petr Novak" "222123456" 1;2;32 "Ivana Novakova" 222123456" 3;4;5Komu tedy patri objednavka 3? A jak by jsi zajistil v DB, ze se Ti stejna chyba nevyskytne? Ale to je OT mimo toto tema

Tak duplicita je problem vsude :) Kazdopadne jak rikam, neni nic snazsiho, nez pustit jednou za cas nejaky skript, ktery to vyresi a zaznamy bez relace odmaze. Stejne se musi na podobne velkych db provadet udrzba jako napr. defragmentace apd, takze proc to neresit u toho :)

pardon, ted jsem si precetl, ze pouzivas kompozitni klic, to pak ano, ale u mysql bych se toho z vykonnostnich duvodu bal - pokud to pole bude dlouhe---------- Příspěvek doplněn 17.06.2011 v 14:08 ----------mytrix:bohuzel, protoze musim :o) user se musi dozvedet, ze se stala chyba a musi ji resit

si ma zle pochopil...ten model co som poslal je model tried nie DB model (som to blbo pomenoval) ! v zivote by ma nenapadlo robit v db atribut typu poledb model by bol: customer(#id, meno, tel_cis) , tovar(#id, nazov), objednavka(#id_osoby,#id_tovaru, datum)myslel som to takto :Tovar1 "hracka" 2 "teniska"Customer1 "Petr Novak" "222123456" 2 "Ivana Novakova" 222123456" 3 "Ivan Novak" 333323456" Objednavka 1 1 17.6.20111 2 17.6.20112 1 17.6.20113 1 17.6.2011mam pocit ze cele nedorozumenie vzniklo kvoli tomu ze na zaciatku si pisal o objektoch a ja tiez,cize sme kecali o aplikacnej urovni... keby si povedal ze myslis databazove tabulky tak tam ti nikdy nebudem radit pole...