SQL/ deklaracja indeksów

0

Cześć,
mam takie pytanie. Jaka jest różnica w tworzeniu indeksów pomiędzy:

  1. zadeklarowaniem indeksów od razu przy poleceniu CREATE_TABLE

a

  1. zadeklarowaniem ich po stworzeniu tabel ?

Rozwiązanie numer 1 wydaje się być mniej czasochłonne, ale czy nie będzie gorsze pod względem późniejszych modyfikacji, tj. trudniej będzie poddawać indeksy zmianom ?

0

nie ma żadnej różnicy. Po prostu nie zawsze na etapie tworzenia tablicy wiesz jakie indeksy będą Ci potrzebne i często zachodzi potrzeba zdefiniować nowe/zmienić (usunąć i stworzyć) istniejące. Koniec końców jakbyś nie stworzył indeksu to on potem działa, i "wygląda" tak samo.

0

Hmmm... czyli chcesz powiedzieć że to nie ma znaczenia tak znaczeniu ogólnym, tylko w zależności od sytuacji ? (tj. w zależności od tego czy wiemy jakie indeksy będą nam potrzebne czy nie)

0

nie bardo rozumiem Twoje pytanie.
Pytałeś wcześniej czy jest różnica pomiędzy indeksem stworzonym podczas tworzenia tabeli a później - nie ma.
Prawda jest taka, że "zapotrzebowanie" na konkretny indeks może się zmieniać wraz ze wzrostem ilości danych oraz tego co chcemy z tych danych wyciągnąć. Baza danych, szczególnie duża to jest żywe stworzenie i je trzeba cały czas dopieszczać aby działała szybko

0

Jest jedna subtelna rożnica jeśli zakładasz indeksy przed załadowaniem danych albo później. Otóż często szybciej jest najpierw wrzucić dane a potem założyć i wygenerować indeks, niż pakować wszystko do bazy z włączonym indeksem ;)

0

Shalom, mógłbyś uściślić ? Tj. czy to robi różnicę w czasie działania przy większych bazach ?

0

A może jest jakaś różnica jak będziemy przenosić skrypty na inny serwer ?

0

po prostu load dużej ilości danych a potem stworzenie indeksu jest czasowo krótszy niż stworzenie indeksu a następnie load dużej ilości danych. Dzieje się tak ponieważ każdy indeks na tabeli powoduje wzrost czasu jaki baza potrzebuje na wstawienie rekordu do tej tabeli bo musi jeszcze uaktualnić indeksy

0

@hunky przeczytaj jak działają tablice hashujące i jak działają drzewa binarne (szczególnie drzewa B i B+) bo na tej zasadzie opierają się w większości indeksy bazodanowe (oczywiście są też inne, ale raczej do specyficznych zastosowań). Ogólnie chodzi o to że każde dodanie nowego elementu powoduje konieczność aktualizacji indeksu, co może być dość kosztowne, bo wymaga rozwiązywania konfliktów w tablicy hashującej, albo rotacji w drzewie binarnym. Stworzenie indeksu na bazie wypełnionej danymi częściowo omija te problemy i stąd jest szybsze.

0

Shalom, dzięki. Wynika że drugie rozwiązanie (zadeklarowanie ich po stworzeniu) może być szybsze, czego trochę się domyślałem ;)

0

dalej nie rozumiesz. Jeśli uważasz, że stworzenie tabeli, potem zadeklarowanie indeksów i na koniec rozpoczęcie normalnego używania bazy (coś się dodaje, coś zmienia, coś się pobiera) będzie szybsze od stworzenie tabeli i indeksów i rozpoczęcie normalnego używania bazy to nie będzie.
Szybsze będzie tylko w jednym wypadku - tworzysz bazę, ładujesz do niej np 1mln rekordów i tworzysz indeks. To będzie szybsze.
Normalne bazy np. podczas wgrywania backupu (normalna rzecz przy np. przenoszeniu się na inny serwer) same tworzą bazę, tabele, itp i same dbają o to, żeby indeksy i wyzwalacze zostały stworzone PO załadowaniu danych. Ale to jest jednorazowa operacja a nie normalna praca.
Indeksy zostały stworzone w konkretnym celu - przyśpieszyć wyszukiwanie, ale jak większość rzeczy mają one skutki uboczne - w tym wypadku wydłużenie operacji dodawania/zmiany danych. W normalnych bazach czas, jaki narzucają przy dodawaniu/zmianie danych jest pomijalny w stosunku do czasu jaki się zyskuje podczas wyszukiwania. W szczególnych przypadkach (ładowanie dużej ilości danych) są jednak niepożądane i wtedy się je wyłącza/usuwa.

0

@abrakadaber to trochę za duże uproszczenie ;) O ile w przypadku indeksów primary to jest prawda, o tyle z secondary bywa różnie. Niektórym ludziom się wydaje że założenie indeksu zawsze przyspieszy korzystanie z bazy, a to nie jest prawda. Jeśli na przykład czytamy wszystkie dane z danej tabeli to może się okazać że szybciej byłoby skorzystać z read_ahead i wczytać wszystko, niż czytać za pomocą indeksów. Na szczęście systemy bazodanowe ogarniają takie sytuacje, ale mimo wszystko indeksy trzeba zakładać z głową, szczególnie indeksy secondary.

1 użytkowników online, w tym zalogowanych: 0, gości: 1