Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Czy to jest poprawne?
Forum PHP.pl > Forum > Przedszkole
Code46
Pozwoliłem sobie powrócić do problemu, który niby został wyjaśniony przez SongoQ.

Mam 2 tabele:

Tabela A:
a_id int primary key
login varchar(20)
haslo varchar(20)


Tabela B:
b_id int primary key
a_id int
imie varchar (20)
nazwisko varchar(20)
adres varchar(20)


Wiem, że można zrobić powiązania między tabelami i jak usuwam z tabeli A wiersz o numerze a_id=1 (np. login:root, haslo:root) i automatycznie usuwa się odpowiedni wpis z tabeli B (np. imie:administrator, nazwisko:systemu, adres:localhost)..

Ale jeśli zrobię to na transakcjach a w kodzie php napiszę 2x instrukcje DELETE (najpierw z tabeli A a potem z tabeli B ) to czy to będzie profesionalne?
Wszystko będzie działać ok, jeśli będziemy robić przez aplikacje. A jeśli ktoś będzie chciał coś usunać ręcznie? To usunie login, hasło, ale pozostałe dane pozostaną w drugiej tabeli. Więc robić powiązania czy nie?
sobstel
oczywiście powiązania zapewniają lepszą spójność BD i uniemożliwiają przypadkowe usunięcie tych danych których byśmy nie chcieli. zresztą sam już sobie na to odpowiedziałeś.
Leezard
powiazanie i wymuszenie wiezow integralnosci czyli cos jak ON DELETE CASCADE itp daja ci to ze nie zostana ci nigdzie zbedne dane, jesli usuwasz dane z jednej tabeli to jesli tak wymusiles to automatycznie zostana skasowane te w drugiej tabeli, z kolei jak chcesz usunac z tej drugiej dane majaca powiazanie z innymi danymi w innej tabeli to system odmowi usuniecia danych poniewaz naruszy to wiezy integralnosci bazy.

w momencie kiedy nie masz tych polaczen, mozesz dowolnie usuwac sobie co chcesz skad chcesz poniewaz dla ciebie te polaczenia istnieja niejako umownie podczas operacji na bazie w twojej aplikacji czyli recznie mozesz wszystko robic. dlatego wg mnie jesli jest to uzasadnione to wypada to zastosowac tym bardziej jesli ktos chce recznie mieszac w bazie. wtedy nie bedize wiedzial o twoich umownych powiazaniach i wysypie ci cala aplikacje, a jak narzucisz mu wymuszanie wiezow integralnosci to moze usunie rekordy, ale nie naruszy ci spojnosci bazy, nie bedizesz mial rekordow "zombie" ze tak powiem winksmiley.jpg

a co do tych 2x delete to to jest wlasnie ta twoja umowa ze w tym momencie istnieja wiezy i je uwzgledniasz, ale po co skoro baza ma wbudowane mechanizmy do tego sluzace i mozliwe ze sa szybsze i wydajniejsze niz wykonywanie 2 zapytan delete z poziomu aplikacji. no a jesli juz bardzo chcesz te 2x delete to bez transakcji nie przejdzie (znowu probelm spojnosci bazy)
Code46
Cytat(Leezard @ 2005-04-20 21:24:34)
powiazanie i wymuszenie wiezow integralnosci czyli cos jak ON DELETE CASCADE itp daja ci to ze nie zostana ci nigdzie zbedne dane, jesli usuwasz dane z jednej tabeli to jesli tak wymusiles to automatycznie zostana skasowane te w drugiej tabeli, z kolei jak chcesz usunac z tej drugiej dane majaca powiazanie z innymi danymi w innej tabeli to system odmowi usuniecia danych poniewaz naruszy to wiezy integralnosci bazy.

w momencie kiedy nie masz tych polaczen, mozesz dowolnie usuwac sobie co chcesz skad chcesz poniewaz dla ciebie te polaczenia istnieja niejako umownie podczas operacji na bazie w twojej aplikacji czyli recznie mozesz wszystko robic. dlatego wg mnie jesli jest to uzasadnione to wypada to zastosowac tym bardziej jesli ktos chce recznie mieszac w bazie. wtedy nie bedize wiedzial o twoich umownych powiazaniach i wysypie ci cala aplikacje, a jak narzucisz mu wymuszanie wiezow integralnosci to moze usunie rekordy, ale nie naruszy ci spojnosci bazy, nie bedizesz mial rekordow "zombie" ze tak powiem winksmiley.jpg

a co do tych 2x delete to to jest wlasnie ta twoja umowa ze w tym momencie istnieja wiezy i je uwzgledniasz, ale po co skoro baza ma wbudowane mechanizmy do tego sluzace i mozliwe ze sa szybsze i wydajniejsze niz wykonywanie 2 zapytan delete z poziomu aplikacji. no a jesli juz bardzo chcesz te 2x delete to bez transakcji nie przejdzie (znowu probelm spojnosci bazy)

Dziękuje. Dodałem transakcje wszędzie tam gdzie używam DELETE, UPDATE lub INSERT.
Przerobię baze na powiązania i pozmieniam kod php.
Gość_Code46
Cytat(Leezard @ 2005-04-20 21:24:34)
powiazanie i wymuszenie wiezow integralnosci czyli cos jak ON DELETE CASCADE itp daja ci to ze nie zostana ci nigdzie zbedne dane, jesli usuwasz dane z jednej tabeli to jesli tak wymusiles to automatycznie zostana skasowane te w drugiej tabeli, z kolei jak chcesz usunac z tej drugiej dane majaca powiazanie z innymi danymi w innej tabeli to system odmowi usuniecia danych poniewaz naruszy to wiezy integralnosci bazy.

w momencie kiedy nie masz tych polaczen, mozesz dowolnie usuwac sobie co chcesz skad chcesz poniewaz dla ciebie te polaczenia istnieja niejako umownie podczas operacji na bazie w twojej aplikacji czyli recznie mozesz wszystko robic. dlatego wg mnie jesli jest to uzasadnione to wypada to zastosowac tym bardziej jesli ktos chce recznie mieszac w bazie. wtedy nie bedize wiedzial o twoich umownych powiazaniach i wysypie ci cala aplikacje, a jak narzucisz mu wymuszanie wiezow integralnosci to moze usunie rekordy, ale nie naruszy ci spojnosci bazy, nie bedizesz mial rekordow "zombie" ze tak powiem winksmiley.jpg

a co do tych 2x delete to to jest wlasnie ta twoja umowa ze w tym momencie istnieja wiezy i je uwzgledniasz, ale po co skoro baza ma wbudowane mechanizmy do tego sluzace i mozliwe ze sa szybsze i wydajniejsze niz wykonywanie 2 zapytan delete z poziomu aplikacji. no a jesli juz bardzo chcesz te 2x delete to bez transakcji nie przejdzie (znowu probelm spojnosci bazy)

A czy mogę stosować połączenia cascadowe w transakcjach?
Leezard
nic nie wiem o tym zeby nei mozna bylo stosowac, w koncu sa to 2 najwazneijsze mechanizmy utrzymujace baz w jako takim stanie, wiec mysle ze powinny ze soba grac

najlepiej przetestuj winksmiley.jpg
Jarod
Moim skromnym zdaniem lepiej ustawić klucze obce bez powiązań kaskadowych i stosować tylko transakcje

Pozdrawiam
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-2025 Invision Power Services, Inc.