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:3 minuty
- Postów:6622
- Rejestracja:około 11 lat
- Ostatnio:30 minut
- Postów:8399
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 2 godziny
- Postów:104
0
Zwłaszcza że w dużych projektach/bazach nie stosuje się delete
Zobacz pozostałe 13 komentarzy
@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