Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Blokowanie tabeli
Forum PHP.pl > Forum > Bazy danych > MySQL
wijet
Mam tabele na której intensywnie wykonywane są INSERTY, SELECT raz na tydzień do generowania raportów.
Istnieje możliwość że dwaj użytkownicy będa chcieli wstawić w tym samym czasie wiersz do tabeli.

Mam własną klase obsługi bazy, moje pytanie jest nastepujace czy wystarczy

  1. <?php
  2.  
  3. function Query($SqlQuery)
  4. {
  5.   if(ereg('INSERT',$SqlQuery))
  6.    {
  7.        //kod zablokowania tabeli do zapisu odczyt dozwolony
  8.    }
  9.    //dalszy kod tej metody
  10.  
  11. //odblokowanie tabeli
  12. }
  13.  
  14. ?>


Aby zabezpieczyc sie przed taka sytuacją na 100%? a tabela MyISAM
Kinool
hmm moze przejdz na InnoDB i zrob transakcje smile.gif a jakich INSERTOW sie boisz?? bo niebardzo cie rozumie smile.gif tego ze ktos wyiera dane a ktos inny w tym czasie wstawia cos do tabeli?

bardziej nalezy sie przejmowac UPDATE niz insert bo tutaj jest zagrozenie gdy dwie osoby edytuja ten sam rekord
wijet
Wydaje mi się że nie potrzebuje tych możliwości jakie daje InnoDB wystarczy do tego MyISAM.
Boje sie że jednocześnie wysłane zostanie INSERT od odwóch klientów.
Chodzi mi oto czy jedno z tych zapytań wpadnie do kolejki, a nastepnie zostanie wykonane czy MySQL na chama bedzie próbował wykonać dwa(jakoś) worriedsmiley.gif
a może warto użyć INSERT DELAYED i to załatwi sprawe ?
kszychu
Obydwa zostaną wykonane, nie musisz się tym przejmować. Przejmować się należy UPDATE'ami a nie INSERT'ami.
wijet
Zakładam że użytkownik którym skrypt loguje się do bazy ma możliwość Tylko
i wyłącznie INSERTowania.
A tak dla mojej wiedzy w przypadku UPDATEów wystarczy blokować tabele do zapisu a można zostawić odczyt? MyISAM
Kinool
jezeli dwuch userow wstawia cos do tej samej tabeli (zakladam ze kozystasz z pola auto_increment) wiec ktorez z nich zawsze trafi jako pierwsze smile.gif wiec ni musisz sie tym przejmowac, inaczej jesli klucz glowny sam przydzielasz za pomoca jakiegos schematu, wtedy mzoe sie zdazyc ze dwie osoby dostana ten sam identyfikator wiec ta ktorej zapytanie bedzie pierwsz wykona sie poprawnie a tej innej osoby wygeneruje blad

Cytat
A tak dla mojej wiedzy w przypadku UPDATEów wystarczy blokować tabele do zapisu a można zostawić odczyt?


skoro jedna osoba bedzie mogla (miala prawa) do zrobienia UPDATE to czemu inna nie smile.gif jest to sztandarowy przyklad problemu rezerwacji biletow smile.gif dwie osoby cha zamowic bilet, zadaja zapytanie do boazy czy sa wolne mijsca, jest wolne wiec jedna i druga osoba rezerwuja miejsce (nie swiadome swojego istnienia:)) gosc, ktory pierwszy wysle formulaz dostanie bilet a gosc numer 2 wyplni frmulaz, kasa zostanie mu scagnieta z konta a biletu nie dostanie tongue.gif i dlatego nalezy sie martwic UPDATE smile.gif
wijet
Nie chodzi mi o użytkownika portalu czy aplikacji php tylko o użytkownika bazy danych, który powinien miec maksymalnie waskie uprawnienia.
W wypadku błedu pozwalajacego na wstrzykniecie swojego kodu SQL np "DELETE from tabelka" nie wykona sie bo użytkownik bazy nie ma takich uprawnien, o takiego użytkownika mi chodziło.
spenalzo
No to od tego są uprawnienia użytkowników, a nie blokowanie tabel.
wijet
Nie chodzi mi o użytkownika portalu czy aplikacji php tylko o użytkownika bazy danych, który powinien miec maksymalnie waskie uprawnienia.
W wypadku błedu pozwalajacego na wstrzykniecie swojego kodu SQL np "DELETE from tabelka" nie wykona sie bo użytkownik bazy nie ma takich uprawnien, o takiego użytkownika mi chodziło.
spenalzo
...? blink.gif
kszychu
Cytat(wijet @ 2006-02-03 14:46:43)
Nie chodzi mi o użytkownika portalu czy aplikacji php tylko o użytkownika bazy danych, który powinien miec maksymalnie waskie uprawnienia.
W wypadku błedu pozwalajacego na wstrzykniecie swojego kodu SQL np "DELETE from tabelka" nie wykona sie bo użytkownik bazy nie ma takich uprawnien, o takiego użytkownika mi chodziło.

Baza mysql, tabele user, db, tables_priv i pozostałe. Tam definiujesz uprawnienia dla użytkownika bazy danych.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.