PHP & MySQL ochrana databaze – PHP – Fórum – Programujte.com

Dobry den,

Co poznam mysqli tak ono to rovno vykona. A ak riesim nejaky import a pripadne v polovice mi to zlyha tak je problem s db. Napadli ma tieto riesenia:

1.) temp struktura tabuliek a nasledme move. Ale to nie je moc dobre lebo ked sa jedna tabulka odkazuje na druhu tak potom mi tam nebude sediet ID. Takze aj tak by som potreboval mnoho sql na opravu zoznamomov a ked to v nejakom procese zlyha napriklad vypadne elektrika tak je koniec a db je zasvinena

2.) zaloha danej struktury ale to tiez nie je moc dobre pretoze neriesi tieto veci a.) medzi zalohou a pripadnim spadnutim a naslednej obnove mohol nastat zapis pripadne iny import ktory kaskadovo poskodi dalsie a dalsie a pripadne ze boli uspesne tak po obnove tam nebudu.

3.) chcel by som nieco take ze by som importoval len do cache a napriklad cache obsadi nejake ID a bolo by rezervovane. A ked vsetko bude ok pak nejakym jednym SQL prikazom s toho spravit trvaly zaznam.

poradte mi dakujem.

Tomu se říká transakce. Buď se udělá všechno nebo nic.

https://dev.mysql.com/doc/refman/8.0/en/sql-transactional-statements.html

#2 gna
Dobre zahrnuje to aj toto?

zapise zaznam, nasledne sa nacita id

php skript robi dalsie spracovanie v ktorom potrebuje to id a spusti dalsie zaznamy a u niektorych dalsie citania a dalsie spracovanie dat ktory usti k nejakej poslednej sekvencii sql prikaozov.

Cize inymi slovami neni mozne spravit kolekciu jedneho sql dotazu.

Samořejmě by nebylo od věci dělat ptákoviny mimo transakci, ale jo, to je její pointa - začneš transakci, pak uděláš X příkazů a nakonec změny uložíš nebo zrušíš.

#4 gna
okay pojdem si to nastudovat a spravit par hokusov  pokusov na teste.

Este jedna otazka php umoznuje nieco take ako $$var (kde $var defunuje nazov premenej) alebo &@var kde mozem riesit prepajanie struktur napriklad:

$a = 10;
$b = 20;
$arr = array(&$a,&$b);
var_dump($arr);
// vypise ze to ma hodnoty 10 a 20.

$a = 100;
$b = 200;
var_dump($arr);
// vypise ze to ma hodnoty 100 a 200

da sa nieco taketo podobne spravit ? napriklad ze db by bola prepojena v systeme ze ked hocikedy ci v php, alebo externym programom alebo phpmyadmin a pod zmenim jednu z  buniek tak zmeny nastanu okamzite aj v ostatnych tabulkach ? cize ako keby roznie bunky z roznych tabuliek by smerovali ako by na jednu adresu ? Coz by znamenalo ze ked sa zmeni jedna bunka tak sa zmenia vsetky bunky ktore smeruju na tu adresu.

#5 Milan
Udělat se to dá přes gettery a settery, ale snad nikdo rozumný to dělat nebude.

Ono to vypada dobre.

$db->query("SET AUTOCOMMIT=0;");
$db->query("START TRANSACTION;");
$a = $db->write("test","val=25");   //true
$b = $db->write("test","val=3d2");  //false
if($a && $b){
  $db->query("COMMIT;");
}else{
  $db->query("ROLLBACK;");
}

Funguje to ale nevracia to AUTO_INCREMENT. Ako to fixxnut ?

#7 Milan
Omyl. Nevypadá to dobře.

#8 Kit
preco myslis ta trieda je mnou vytvorena aby som nemusel neustale pisat sql.

#9 Milan
Máš tam SQL injection a je to zbytečně komplikované. Zkus si to pro víc než jednu tabulku a víc než jen 2 sloupce. K čemu je ti ten AUTO_INCREMENT?

#10 Kit
S tym ID ty to snad nemusim  vysvetlovat, Napriklad co myslis preco naprikald tato stranka ma napriklad:

http://programujte.com/forum/vlakno/194653-php-mysql-ochrana-databaze/#pridani_prispevku

cize ID = 194653 vlakna.

Ten kod je testovaci aby som otestoval funkcnost tam kde to bude treba. Ale nevracia to auto_incerement toho id. Nasledne podla ID moze lahko vyhladat, upravit, vymazat, riesit prepojenia medzi tabulkami a pod.

A co sa tyka autoinkrementu to je zakladna vec. mame dve riesenia:

1.) bez auto_incerement a manualne ID: precitanie posledneho, manualna inkrementacia a zapis. Problem je ze medzi nacitatanim a zapisom sa tam moze vsunut iny zaznam inym uzivatelom.

2.) auto_incerement: zapises pak zistis ID. a mozes robit navaznosti s inymi tabulkami.

Riesim jeden zlozitejsi import a a potrebujem osetrit, pripad keby to v procese vykonavania zlyhalo a meostali zaznamy v db.

Rad sa neham poucit. Ako by si to ty riesil ? Ukaz example. Dakujem

#10 Kit
Este som zabudol odpisat na sql injuction. S tohto examplu, ktory je v style hello world. Sa ani z daleka neda hovorit o SQL injuction. Ziadnym sposobom sa tam s tohto nevkladaju priamo do SQL parametre z napriklad $_GET , $_POST , useragent , cize externych zalezitosti.

Napriklad ked s $_GET by ti priamo doskladalo SQL mozeme sa bavit o uprave SQL konania, Ale ked na vstupe napriklad z _GET mas kontroly napriklad ze to moze byt len integer cize strikne sprecifikujes co to ma prepustit dalej uz potom sa branis ...

Jak uz psal Kit driv, nesmis delat ptakoviny :)
Kdyz chces udelat import databaze, tak preci nepotrebujes resit autoincrement, ne? To naimportujes uz s ideckami.
Kdyz chces pridat 10 radku ke stavajici db, tak na to nepotrebujes transakce (ty maji vyznam pro ten import, spis, pro 10.000 radku), ne? A navic, vetsina sql ti to id umi vratit do sql promene, kterou muzes vyuzit v dalsi serii prikazu.

Zkus tady pridat nejake realne sql prikazy, ktere potrebujes. Nemusis vypisovat vsechny sloupce.

Navic, pro import muzes poslat do db vygenerovany soubor s sql prikazy, zazipovany. Tima padem se to bude i rychleji uploadovat. A nehrozi, prilis, ze prekrocis upload-max-file-size a tak.300k zip proti 50MB je sakra rozdil.

#13 peter
1.) nebudem vsade pisat SQL v hlbke kodu na urovni mysqli.

2.) nikdo noehovoril ze to bude 10 SQL, to ze vy by ste to nehali tak nech po sebe neha bordel v pripade, nejakeho konfilktu, je vec vasa.

3.) neresim import database, ale import niecoho co nasledne spracovava, upravuje a pod.

4.) ja som sa pytal na nieco a jediny konstruktuvny tu bol GNA za to velke diki. Ked ked neviete poradit neradte, ked viete poradit poradit. Ked nehcete vies kontruktivne radsej nepiste. Vezmite si priklad z GNA.

Dakujem, o danej problematike neviete nic co riesim a nemam na plane vam vysvetlovat preco to riesim ako riesim.

#12 Milan
Když to budeš psát s SQL, tak to bude stručnější a jednodušší. 

Edit: Trochu jsem to upravil.

$insert = $db->prepare("INSERT INTO inserty (val) VALUES (?)");
$dbh->beginTransaction();
$insert->execute([25]);
$a = $db->lastInsertId();
$insert->execute(["32"]);
$b = $db->lastInsertId();
if ($a && $b){
    $db->commit();
} else {
    $db->rollBack();
}

Metoda $db->lastInsertId() ti vrátí hodnotu posledně vloženého ID.
 

#15 Kit
Dakujem , poskusal som, akurat to ze funguje $db->insert_id; . Vyzera to zaujimavo a prekopem svoju class, spravi mi to usporu kodu.

Este ten rollback nevracia pocitadlo auto_increment ,

#16 Milan
Ovladač MySQLi jsem přeskočil, nikdy jsem ho nebral moc vážně. Tak si to uprav.

Přeskočené ID nikoho nezajímá, neřeš to.

#17 Kit

Logiká veta: `Přeskočené ID nikoho nezajímá` je nesprávna. Logickou negaciou: `Preskocene IS zaujima aspon jedného` sa to dá vyvratit. Kedze to zaujima mna (aj keby to bolo len z akademického dovodu) tak som potvrdit vyrok logickej negacie , cize tvoj vyrok nie je spravny.

Ak vies a chces odpovedat kludne mi odpovedz. Lebo posledny komentar nebol ku nicomu konstruktivny.

#18 Milan
Z logického hlediska máš pravdu, ale tvůj požadavek souvislé řady je prakticky neřešitelný.

#19 Kit

Hypoteticky:  mas miliony zaznamov, k tomu nejake prepojenia s ostatnymi tabulkami. Tym ze by sa neriesili auto_increment pred rollback, tak to ma dosledok ze musi pocitat s vacsim cislo ID a tym aj vacsim typom cisla a priestor ku zaplneniu. Vynasob to z milionmi zaznamami a este aj s prepojeniami a zistis ze sice pri malych DB ti to moze byt jedno, ale pri velkych databazach taketo drobnosti uz hraju belku rolu.

S coho plynie ze musi existovat nieco ako mat pod kontrolou aj auto_increment pri rollbacku.

#20 Milan
Tak si spočítej, kolik je 2^64, což je rozsah datového typu SERIAL. Za jak dlouho to zaplníš, pokud budeš inkrementovat miliónkrát za sekundu?

"S coho plynie ze musi existovat nieco ako mat pod kontrolou aj auto_increment pri rollbacku."

Jenze, u transakce to dela vsechno do pameti.
INSERT On stopne vsechny prikazy pro zmeny, insert, update a pod. Vytahne aktualni stav tabulky, autoincrementy a tak. Vytvori si klon prazdne tabulky. Pak spusti ty prikazy a pri sucess presune do oficialni tabulky.
Cili, se zmeni autoincrement az po uspesnem prekopirovani dat podle autoincrementu te tabulky v pameti.
Kdyz to selze, tak uzavre transakci a odstrani tabulku z pameti. Do puvodni tabulky vubec nesaha.
Teda, takova je aspon ma predstava.

Pri UPDATE si zase zkopiruje zasazene radky a pak je zpetne kopiruje podle id.
Cili, tahle operace by mela byt pres transakce o neco pomalejsi nez ciste insertovani.

Ale, je mozne, ze to databaze delaji uplne jinak, nez si myslim :)

A, mimochodem, by mozna byle lepsi, kdybys prestal kazdeho urazet a povznesl se a na takovy prispevek nereagoval. Uz ti zbyva urazit jen gna a nebude ti tu reagovat nikdo :)

#21 Kit
Za prve serial sa neda pouzit na ID, na to tu je BIG INT s velkostou 8bajtov (2^64). Za druhe tu nejde o pocet dosptupnych ID a ako som tu aj pisal , ide o nabublani velkosti DB. Priklad hovoris tu o puziti 2^64 to je 64bitov. Pri puziti MEDIUM INT (3bajty = 2^24 coz je nieco na 16milionov). A ta zaberana velkost je uplatnena vsade tak kde je to puzite, jednak priamov taj tabulke a jednak vsade v dalsich tabulkach kde je referencia na to ID danej tabulky. Pri velkej DB napriklad kde mas 10milionov zaznamov mas 10^6 * (64-24) = 40*10^6 b = 4.8MB pri jednej tabulky a to este nepocitat ine tabulky kde mas prepojenia. Pri pouziti tvojej logiky to ale pouzijes na kazdej tabulke. Pri malych veciach to je jedno ale pri velkych projektoch aj tieto veci hraju velky rolu. Cu projekty kde mas miliardy, triliony zaznamov kde nemas zopar tabuliek ale mas obrovske mnozstvo tabuliek a pri tych.

#22 peter
Bohuzial, ono sa spravi zaznam, ktory nie je vidiet, co sa tyka auto_incrementu vsak to vidiet je, coz je logicke aby nevznikla kolizia a pod commit sa to ukaze az aj v db trvalo. lenze ked pouzijes rollback tak auto_increment ignoruje. Neposnazi sa nastavit na najnizsiu moznu pocitadla od hodnoty ktora bola po vyvolani TRANSSAKTION a zapisu do danej tabulky

Vo vysledku to dopadne tak ze je tak ze pak unikaju dostupne ID a ty to potom musis kompenzovat vacsim datovym typom premennej v tabulkach.

Mam to vyskusane, ze tam nastava problem pri tom pocitadle.

A co sa tyka k udajnemu mojmu urazaniu. Mozno je tam opodstatnena drzost ale nikoho som tu neurazal. Praveze ja mozem byt urazeny ked na otazku, tu dostavam odpovede typu "odpal". Ja sa len branim a snazim sa drzat konstruktivnej rovine. Ono si streba uvedomit aj uz len z jedneho pohladu (akademicky zaujem). cize aj keby to nemalo ziadny prakticky vyznam. Aj v takom najhorsom moznom scenary si nezasluzim aby mi niekdo posielal take odpovede ake posielal, ja sa len snazim branit voci takym odpovedam a to tym ze ich na to upozornim. Toto cele.

Ako riesenie ma napadlo, plnit si array vsade tam kde som robil nejaky zapis (INSERT) a pri rollbacku spustit manualne u vsetkych tych tabuliek prenastavenie ID pocitadla. Ale ma to niekolko negativ. Za prve je to o hubu, a nechce sa mi verit ze by neexistoval iny sposob elegantnejsi, priamov v mysqli o ktorom neviem a nepodarilo sa mi to najst. A za druhe musim pridat permissiu, k moznej manualnej uprave toho pocitadla, coz sa prieci, ze permisie sa nastavaju na minimum. Ak by stranka len citatala tak uzivatel, ktory vyuziva v php na pripojenie ku db bude mat len citanie. Ked zapis tak aj zapis. Nie je dobre napriklad dat root prava :D to by bola cesta do pekla.

#22 peter
INSERT nestopne všechny příkazy pro změny. Vyzkoušej si to. Na jedné tabulce můžeš provádět více transakcí současně. Jen se nesmí překrývat.