Temat: DELETE FROM - Wątek konwencyjny

Mam do was pytanie na temat konwencji jakie stosujecie w czasie usuwania elementów z Bazy. A dokładniej chodzi mi o usuwanie elementów z listy Detail po usunięciu elementu z listy Master.
W tej chwili spotkałem się z 3 podejściami:
1. Ustawienie ON DELETE CASCADE podczas tworzenia struktury bazodanowej. Zalety : Detaile się usuną gdzie byśmy nie wywołali delete'a na masterze, Wady uzależnienie się od konkretnego silnika bazodanowego.
2. Ustawienie ON DELETE RESTRICT i ręczne usuwanie elementów w kodzie Zalety: Niezależność od silnika bazodanowego. Wady: Spora ilość dodatkowego kodu.
3. Nie usuwanie fizycznie elementów z bazy a tylko ustawienia wskaźnika widoczności. Zalety: Możliwość podejrzenia danych które ktoś z jakiegoś powodu usunął. Wady szybko wyczerpująca się przestrzeń dyskowa.

Temat: DELETE FROM - Wątek konwencyjny

Wojciech Gomoła:
Mam do was pytanie na temat konwencji jakie stosujecie w czasie usuwania elementów z Bazy. A dokładniej chodzi mi o usuwanie elementów z listy Detail po usunięciu elementu z listy Master.
W tej chwili spotkałem się z 3 podejściami:
1. Ustawienie ON DELETE CASCADE podczas tworzenia struktury bazodanowej. Zalety : Detaile się usuną gdzie byśmy nie wywołali delete'a na masterze, Wady uzależnienie się od konkretnego silnika bazodanowego.

Silnik bazodanowy, który nie obsługuje kluczy obcych nie jest wart by go używać.

2. Ustawienie ON DELETE RESTRICT i ręczne usuwanie elementów w kodzie Zalety: Niezależność od silnika bazodanowego. Wady: Spora ilość dodatkowego kodu.

bez sensu

3. Nie usuwanie fizycznie elementów z bazy a tylko ustawienia wskaźnika widoczności. Zalety: Możliwość podejrzenia danych które ktoś z jakiegoś powodu usunął. Wady szybko wyczerpująca się przestrzeń dyskowa.

jeżeli założenia tego wymagają to można tak robić.

Temat: DELETE FROM - Wątek konwencyjny

Wojciech Gomoła:
Wady szybko wyczerpująca się przestrzeń dyskowa.

Miejsce to najtańszy element całej układanki. Osobiście tam gdzie można stosuje wariant nr 3.

BTW: Youtube się kiedyś chwalił, że posiada każdy wrzucony/skasowany (!) film od początku działalności ;)

Temat: DELETE FROM - Wątek konwencyjny

Wojciech Gomoła:
Mam do was pytanie na temat konwencji jakie stosujecie w czasie usuwania elementów z Bazy. A dokładniej chodzi mi o usuwanie elementów z listy Detail po usunięciu elementu z listy Master.
W tej chwili spotkałem się z 3 podejściami:
1. Ustawienie ON DELETE CASCADE podczas tworzenia struktury bazodanowej. Zalety : Detaile się usuną gdzie byśmy nie wywołali delete'a na masterze, Wady uzależnienie się od konkretnego silnika bazodanowego.

Stosowalismy ta metode i na dluzsza mete to nie jest dobre rozwiazanie. Najpowazniejszym problemem okazalo sie, ze takie usuwanie Master/Detail to czesto decyzja logiczna i procedury skladowane zaczely goscic (nie wprost) coraz wiecej logiki biznesowej :((

2. Ustawienie ON DELETE RESTRICT i ręczne usuwanie elementów w kodzie Zalety: Niezależność od silnika bazodanowego. Wady: Spora ilość dodatkowego kodu.

Takiego podejscia nie odwazylbym sie zastosowac przy duzych projektach, latwo mozna zgubic lub pomylic zaleznosci.

3. Nie usuwanie fizycznie elementów z bazy a tylko ustawienia wskaźnika widoczności. Zalety: Możliwość podejrzenia danych które ktoś z jakiegoś powodu usunął. Wady szybko wyczerpująca się przestrzeń dyskowa.

Takie "usuwanie" logiczne ma bardzo duzo zalet. Po pierwsze nie fragmentuje bazy danych. Po drugie optymalizuje prace indeksow. Po trzecie masz pelna informacje dlaczego ten rekord "zniknal" przy rozmowie z klientami. Przestrzen dyskowa nie powinna stanowic duzego problemu, generalnie nie powinno byc zbyt wiele komend "delete" posylanych do bazy. Poza tym duzo latwiej dokupic kolejne dwa dyski do serwera niz bawic sie w codzienne defragmentowanie...

Temat: DELETE FROM - Wątek konwencyjny

Sebastian Pienio:

3. Nie usuwanie fizycznie elementów z bazy a tylko ustawienia wskaźnika widoczności. Zalety: Możliwość podejrzenia danych które ktoś z jakiegoś powodu usunął. Wady szybko wyczerpująca się przestrzeń dyskowa.

Takie "usuwanie" logiczne ma bardzo duzo zalet. Po pierwsze nie fragmentuje bazy danych. Po drugie optymalizuje prace indeksow. Po trzecie masz pelna informacje dlaczego ten rekord "zniknal" przy rozmowie z klientami. Przestrzen dyskowa nie powinna stanowic duzego problemu, generalnie nie powinno byc zbyt wiele komend "delete" posylanych do bazy. Poza tym duzo latwiej dokupic kolejne dwa dyski do serwera niz bawic sie w codzienne defragmentowanie...

To zależy. Jeśli rozważana tabela nie jest ważną tabelą a jedynie jakimś logiem to oczywiście trzeba rozważyć na czym klientowi bardziej zależy - na kupowaniu dysków i przechowywaniu wszystkiego czy też na optymalizacji przestrzeni.

Delete kaskadowy ładnie wygląda w projektach na zaliczenie, ale w realnym świecie często relacje z tabelami tak się komplikują, że łatwiej wychodzi wyłączyć kaskadę niż się pocić w jej omijaniu.

Temat: DELETE FROM - Wątek konwencyjny

Jak dla mnie są tu pomylone dwa pojęcia..

Usuwanie rekordów z bazy danych i akcja usuwania "czegoś tam" w aplikacji (które może być realizowane jako usunięcie fizyczne np. rekordów w bazie danych lub "oznaczenie" ich jako nie widoczne - opcja 3).

Jeśli chodziło o "akcję usuwania", generalnie jeśli chcemy/musimy zachować historię powiązań między rekordami to oczywiście ukrywamy.

W pozostałych przypadkach sprawa do rozważenia.

"Ukrywanie danych" zmusza nas do oprogramowania takiej sytuacji: czasami chcemy uzyskać dane powiązane, łącznie z tymi powiązanymi do "usuniętych" - czyli ukrytych rekordów. W pozostałych przypadkach musimy zadbać o to żeby wszystko działało tak jakby dane były fizycznie usunięte.

Zasoby to już osobna kwestia, jak poprzednicy pisali - łatwo i tanio można przeskalować rozmiar bazy, łącza itd.

Temat: DELETE FROM - Wątek konwencyjny

Piotr Likus:
To zależy. Jeśli rozważana tabela nie jest ważną tabelą a jedynie jakimś logiem to oczywiście trzeba rozważyć na czym klientowi bardziej zależy - na kupowaniu dysków i przechowywaniu wszystkiego czy też na optymalizacji przestrzeni.

Przestrzen jest tania, szybkosc droga. Toolsy do defragmentacji bazy jeszcze drozsze. Sam odpowiedz sobie na pytanie :)

Temat: DELETE FROM - Wątek konwencyjny

Wojciech Gomoła:
1. Ustawienie ON DELETE CASCADE
2. Ustawienie ON DELETE RESTRICT
3. Nie usuwanie fizycznie elementów z bazy a tylko ustawienia wskaźnika widoczności.

Wg mnie mylisz pojęcia. Przede wszsystkim - restrict służy do czegoś innego niż cascade i w ogóle zapomniałeś o SET NULL, które też się często wykorzystuje.
Gdy kasujesz wątek w forum dyskusyjnym - chcesz żeby skasowało się całe drzewo - czyli cascade.
Gdy chcesz usunąć użytkownika z forum, możesz użyć cascade (i wtedy wytnie wszystkie wypowiedzi), bądź set null (wtedy autor będzie nieznany).
Gdy chesz usunąć grupę użytkowników, ale bez usuwania użytkowników, robisz set null (i jakimś query później wyciągnięcie userów bez grupy i wpisanie ich do innej) albo restrict (i wtedy aplikacja zwróci Ci błąd, że nie można usunąć grupy bo ma referencje).

Temat: DELETE FROM - Wątek konwencyjny

Sebastian Pienio:

Piotr Likus:
To zależy. Jeśli rozważana tabela nie jest ważną tabelą a jedynie jakimś logiem to oczywiście trzeba rozważyć na czym klientowi bardziej zależy - na kupowaniu dysków i przechowywaniu wszystkiego czy też na optymalizacji przestrzeni.

Przestrzen jest tania, szybkosc droga. Toolsy do defragmentacji bazy jeszcze drozsze. Sam odpowiedz sobie na pytanie :)

O jakich toolsach myślisz? I do jakiej bazy?

MySQL: http://dev.mysql.com/doc/refman/5.0/en/innodb-file-def...
DB2: REORG
MS SQL: http://www.sqlhacks.com/index.php/Optimize/Defragment-...
http://technet.microsoft.com/en-us/library/cc966523.aspx
Oracle?

W większości wypadków są to rozwiązania darmowe.Piotr Likus edytował(a) ten post dnia 13.07.09 o godzinie 16:27

Temat: DELETE FROM - Wątek konwencyjny

Piotr Likus:

Przestrzen jest tania, szybkosc droga. Toolsy do defragmentacji bazy jeszcze drozsze. Sam odpowiedz sobie na pytanie :)

O jakich toolsach myślisz? I do jakiej bazy?

MySQL: http://dev.mysql.com/doc/refman/5.0/en/innodb-file-def...
DB2: REORG
MS SQL: http://www.sqlhacks.com/index.php/Optimize/Defragment-...
http://technet.microsoft.com/en-us/library/cc966523.aspx
Oracle?

W większości wypadków są to rozwiązania darmowe.Piotr Likus edytował(a) ten post dnia 13.07.09 o godzinie 16:27

Mowie o sytuacji gdy masz np. klastrowany index po kolumnie nie bedacej int'em. Deragmentacja indeksu to banalna operacja, defragmentacja bazy kosztuje duze pieniadze i ma duzo wiekszy wplyw na jej wydajnosc niz indeks. Do MS SQL uzywamy toolsow za ponad £4000.

Na Oracle nas (jeszcze) nie stac :] a z mySQLem bysmy sie nie odwazyli wypuscic systemu :]

Temat: DELETE FROM - Wątek konwencyjny

Sebastian Pienio:
Na Oracle nas (jeszcze) nie stac :] a z mySQLem bysmy sie nie odwazyli wypuscic systemu :]

No widzisz, wszyscy psioczą na tego MySQLa a ja muszę się obracać w kręgach w których nikt nie odważył się jeszcze użyć Microsoft SQLa :D

A co do tej kwoty to niezłe przegięcie.

Temat: DELETE FROM - Wątek konwencyjny

Piotr Likus:

Sebastian Pienio:
Na Oracle nas (jeszcze) nie stac :] a z mySQLem bysmy sie nie odwazyli wypuscic systemu :]

No widzisz, wszyscy psioczą na tego MySQLa a ja muszę się obracać w kręgach w których nikt nie odważył się jeszcze użyć Microsoft SQLa :D

A co do tej kwoty to niezłe przegięcie.

Ehh, szczerze mowiac czasami wolalbym miec mySQLa na jakims debianku tudziez ubuntu, ale o tym decyduje zbyt wiele czynnikow (company policy, security, integracja z ISA, ActiveDirectory itepe itede - same nudy).

A co do toolow to roznica w wydajnosci - kosmiczna. Warto bylo, chociaz firma produkujaca to delikatnie mowiac nie podchodzi profesjonalnie do swoich...