Załóżmy, że znam podstawy języka SQL i "czuję" różnicę pomiędzy DELETE * FROM db a DROP db. Co dalej mogę zrobić by poszerzyć swoją wiedzę z relacyjnych baz danych? Chodzi mi o kierunek rozwoju.
SQL - Rejestracja:prawie 2 lata
- Ostatnio:prawie 2 lata
- Postów:22
0
Na ten temat baza dla Ciebie to wyłącznie składowisko danych.
Spoko, ale w zasadzie w czym lepsze będzie to od excela?
Zacznij używać excela, zacznij pisać większe programy, gdzie jest więcej użytkowników, a szybciej poznasz problemy, które baza rozwiązuje.
Z perspektywy nauki to jest lepsza droga niż klepanie na sucho teorii, której właściwie na teraz nie potrzebujesz.
- Rejestracja:prawie 22 lata
- Ostatnio:około godziny
- Postów:6626
- Rejestracja:około 11 lat
- Ostatnio:4 minuty
- Postów:8398
1
rafal95p napisał(a):
Załóżmy, że znam podstawy języka SQL i "czuję" różnicę pomiędzy
DELETE * FROM dbaDROP db. Co dalej mogę zrobić by poszerzyć swoją wiedzę z relacyjnych baz danych? Chodzi mi o kierunek rozwoju.
to JOINów się poucz, GROUP BY itp. a nie, że tylko kasowania się zachciało.
edytowany 1x, ostatnio: LukeJL
- Rejestracja:ponad 6 lat
- Ostatnio:około 4 godziny
- Postów:104
0
Zwłaszcza że w dużych projektach/bazach nie stosuje się delete
A to niby czemu?
ponieważ jak zaczniesz usuwać rekordy to rozwalisz indexy.. stosuje sie update, widoki itd.. a juz gdzie widziałem ze tylko inserty. Masz wtedy pełną historie zmian.
można.. ale to nie jest dobra praktyka aby usuwać rekordy. A gdy ma sie ogromne bazy danych to nikt nie odbudowuje rekordów
A czemuż to?
W jakim silniku usunięcie rekordu z tabeli rozwala indeksy?
czyil rozumiem, ze nigdy z db nic nie usuwacie tylko ustawiacie flage zeby bylo widac ze jest outdated? wtf
Czemu pytasz w liczbie mnogiej? Tylko jeden człowiek się za takim rozwiązaniem opowiada.
Cytując klasyka "kto dobrze wie nie musi pytać" i "tu stać się może coś strasznego" ;) Parent: 100 wierszy (dane referencyjne), Child dużo rekordów. Powiązanie via FK. Procesy często wstawiają do Childa. Ziomek dodaje jeden rekord od parenta, kończy transakcję. W kolejnej usuwa rekord z parenta. W zależności od tego jak w danym silniku wygląda zapewnienie spójności referencyjnej, może stać się coś strasznego (przeczesanie dużej tabeli child, by bezpiecznie usunąć parenta, zajmuje czas, co w połączeniu z mechanizmem locków dla indeksu, może zabić wydajność).
Co do indexu, to usuwanie może prowadzić do fragmentacji (pytanie jak często to delete występuje), a co za tym idzie do nieefektywnego wykorzystania przestrzeni dyskowej (indeks rozrasta się "w prawą stronę", np. dostawiamy dane z kluczem z sekwencji i co jakiś czas usuwamy dane historyczne, segmenty indeksu rozrastają się i fizycznie zajmuje np. 20GB, a indeksuje tabelkę o rozmiarze 3G, z czego 17gb to "dziury").
@WeiXiao: zazwyczaj usuwanie rekordu polega na oznaczeniu go jako usunięty, a usunięcie użytkownika polega na anonimizacji danych osobowych. Nie wyobrażam sobie, żeby jakikolwiek system transakcyjny lub księgowy miał dziury w transakcjach bo trzeba było usunąć dane użytkownika - to nie przejdzie przez żaden audyt finansowy.
temu się indexy przebudowuje co jakiś czas o.O
@flinst-one: po co przebudowywać indeksy skoro można na starcie dobrze zaprojektować? :) Przebudowanie takiego partycjonowanego index organized nie jest takie trywialne jakby się mogło wydawać.
..o widzę ze temat indeksów został wyjaśnione to już nie musze tego tłumaczyć.. pracuje z bazami DB2, SQL sever, Mysql zatem tu to obowiazuje. Oczywiście można kasować a potem odbudować indexy.. jak ktoś się nudzi w pracy to powodzenia. I jak tu kolega fajnie napisał... można na starcie dobrze zaprojektować.. Właśnie tak to sie projektuje że jeżeli dany rekord ma być nie brany uwagę ustawia się flagę (np tworzymy kolumnę anuluj, czy status) który zgodnie z indexem ma nie zostać wyświetlony.
@sight: czyli zamiast robić delete i co jakiś czas runstaty na indexach (w przypadku db2) lepiej dodać kolejną kolumnę ? Z d**y rozwiązanie. Zbieranie statystyk idzie po całej tabeli i im więcej danych, tym dłużej to trwa. Postgres używa mvcc, tam nie ma fizycznego delete, ale i tak vacuum jest potrzebne (jakbyś systemu nie zaprojektował).
Nie do końca tak z tymi statystykami. Sporo zależy od możliwości jakie oferuje silnik (np. samplowanie % segmentów/bloków, zbieranie per partycja, zamrażanie statystyk). Zauważ, że w postgresie przy delete będziesz zostawiony wiersz poprzedni, więc postgresowi z przypadku vacuum wszystko jedno czy to update czy delete. Przy fizycznym delete musi jeszcze zaktualizować indeks (vacuum) :-) Przy update niekoniecznie (o ile nie masz indeksu na flagę DELETED). Co do dużych tabel przy projektowaniu trzeba brać pod uwagę ficzery typu partycjonowanie, columnar storage.
@flinst-one: Hej moim zdaniem bardzo dobre rozwiązanie.. mam tabele po miliony rekordów.. robisz indexy po np statusach bez anulowania.. Gdy budujesz aplikacje i potrzebujesz widok dla przykładu otwartych zamówień to budujesz tak index aby pokazywał Ci nie anulowane i np z jakim statusem.. od lat mamy firmie takie gigantyczne bazy danych i to śmiga w ułamkach sekund... budujemy raportu z zakresami rocznymi.. Jak masz okazję to sprawdzić no może nie na DB2 ale na SQL serwerze to podłącz sobie taką bazę i w sql management studio masz obliczanie kosztów zapytania...
rafal95p