[SQL] duplikaty, podwójne wpisy w bazie danych

[Rybik]

operacja wysokiego ryzyka, nie stosowac profilaktycznie tylko po wykonaniu kopii bazy i dobrze wiedząc co i po co się robi !

Jezeli zdarzyloby sie komus posiadac duplikaty w bazie danych to polecam takie polecenie SQL

 
ALTER IGNORE TABLE tabela ADD UNIQUE INDEX(kolumna, kolumna1);

w tabeli zostana usuniete wszystkie "zapasowe" rekordy o identycznych polach "kolumna" i "kolumna1" oczywiscie jeden wpis pozostanie.

Ilosc kolumn nieograniczona a warto sprawdzac 2 zeby soebie nie spaskudzic czegos. Zdublowane wpisy w tabelach joomla nalezy filtrowac po polach, title, title alias, i jakies dodatkowe typu ordering.

czasami moze byc wymagane podanie dlugosci porownania np kolumna(100) co znaczy ze pole kolumna bedzie sprawdzane na obecnosc identycznych pierwszysch 100 znakow.

[rkubera]

Tak, patent dobry ale rzeczywiście niebezpieczny między innymi w przypadku, gdy nie obsługuje togo kod PHP. W takim przypadku mogą zdarzyć się cuda w systemie. Indeksy dodatkowo przyśpieszają wyszukiwanie po bazie. Natomiast większa liczba pól w tym co podałeś może dosyć mocno powiększyć rozmiar bazy.
Mimo wszystko indeksy to to, co tygryski lubią najbardziej.

[Rybik]

z poziomu skryptow to polecam zabezpieczac sie wstepnie przed duplikatami przy wpisach a to polecenie glownie do naprawy bazy - z poziomu MyAdmina.

1. Nie bardzo rozumiem jak ilosc pol porownania moze powiekszyc rozmiar bazy ?
2. Tez nie bardzo rozumiem dlaczego php ma nie wykonac zapytania sql ? php wysyla zapytanie, polecenie dziala dla MySql 4, uzywa metody porownan ustawionej w bazie (najczesciej utf binary-safe) wiec php nie powinno miec nic do powiedzenia.

[rkubera]

Witaj Rybik.

1.Budowa indeksu wiaże się z tym, że w bazie budowana jest dodatkowa nazwijmy to przestrzeń dla indeksu (jest to fizyczny plik), w której dla każdego połączenia pól wskazanych podczas budowy indeksu wpisywany jest wskaźnik do fizycznego położenia danych w tabeli. Właśnie ta dodatkowa przestrzeń dla indeksu powiększa rozmiar bazy. Im więcej pól buduje indeks, tym bardziej rośnie jej rozmiar. Znam przypadki, gdy indeks zajmuje więcej jak tabela.

2. Wykonanie zapytania (insertu) uda się - ale zwróci false jako wynik - bo będzie chciał stworzyć dubla. W przypadku, gdy skrypt php np. na początku zakłada pole - nieunikalne a następnie zakłada na podstawie tego wpisu inny wpis w innej tabeli - może to się rozjechać w wyniku tego, że pierwszy rekord nie powstał. Jeżeli programista nie zadbał o unikalność to pewnie nie zadbał też o sprawdzenie kodu powrotu z zapytania. To oczywiście gdybanie, ale ręczne zakładanie unikalności do komponentów napisanych przez innych może spowodować taką sytuację. Poza tym mogą zostać pogubione "relacje" po id między tabelami.

Pozdrawiam,
Radek.

[Rybik]

no prosze, wreszcie ktos ma cos do powiedzenia na forum a nie tylko "jak dodac artykul" ;)

co do budowy indeksu to chyba tymczasowo powstaje taki plik ?

ad 2. to juz dla mnie na granicy pojmowania ale swiadczy tylko na korzysc argumentu zeby budowac skrypty z wlasnym zabezpieczeniem przed dublami i nie korzystac z tego polecenia inaczej jak recznie / awaryjnie z poziomu MyAdmina

[rkubera]

Dzięki Rybik za słowa uznania, ja na tym forum widzę osoby co nieźle znają tematykę i od których możemy się dużo nauczyć.

Do do indeksów- niestety przestrzeń na indeksy nie jest zwalniana, bo wtedy co zapytanie by musiała być ponownie alokowana :-D i zamiast przyspieszać by spowalniało.

Ale w przypadku gdy zależy nam na prędkości i wydajności - to koszt jest niewielki. Jeżeli chcemy sortować np. po nie zaindeksowanym polu to trwa to znacząco dłużej i bardziej obciąża serwer niż przy posiadaniu indeksu na to pole. W przypadku budowy indeksu obiąża to tylko raz - przy pierwszej inicjacji indeksu. Potem wielokrotne sortowanie jest szybsze i mniej obciążające.

[Rybik]

Ha, no widzisz, bo ja ta operacje potraktowalem jako Fire&Forget ze mi duplikaty usunie i po krzyku to az sobie poczytam ... a czas juz najwyzszy bo z SQLem bede musial sie zaprzyjaznic bardziej