Ostatnimi czasy budowałem dość skomplikowany projekt, jeżeli chodzi o złożoność zapytań i wykonywanych przez nie operacje matematyczne. Pomimo tego, że aplikacja była doskonale przemyślana, a struktury bazy danych perfekcyjnie jej podporządkowane, gdzieś tkwił problem, bowiem jedno z zapytań generowało pozornie prosty (wizualnie) rezultat, baza reagowała na zapytanie dopiero po 2.5 sekundy dla 30k+ rekordów. Patrząc na strukturę kluczy i zapytania, zwłaszcza, że pola, na których operowałem były różnego rodzaju liczbami i datami zacząłem się poważnie martwić i rozkładać zapytanie na czynniki pierwsze, kończąc na warunkach. Wyobraźcie sobie moje zdziwienie, gdy doszedłem do tego, że całe obciążenie (ponad 2.3 sekundy) generował warunek:

WHERE DATE(ticket_date) >= " ... "

Gdzie ticket_date to pole typu DATETIME. Od razu doszedłem do wniosku, że w parze idzie złe przygotowanie danych przez PHP, a angażowana jest w to wszystko baza, na której forsuje się użycie funkcji DATE(). Przynajmniej dla 30k+ rekordów zindeksowanego pola. Prosty zabieg zamiany jednej linijki kodu na drugą przyniósł porządane efekty.

$aTerms[] = 'DATE(ticket_date) >= "' . $sDate . '"'

$aTerms[] = 'ticket_date >= "' . date('Y-m-d H:i:s', strtotime($sDate)) . '"'

Budując aplikację zwracam szczególną uwagę na strukturę bazy, indeksowanie pól, rysuję diagramy przewidujące wykorzystanie danych pod różne zapytania, ale… tak banalny błąd przy przeanalizowanej aplikacji rozłożył mnie na łopatki. Z drugiej strony, zapomniałem o jednej bardzo ważnej rzeczy: maksymalnym odciążeniu bazy danych przy preparowaniu argumentów warunków, skoro warunki te mogą być w odpowiedni i przede wszystkim szybki sposób spreparowane na poziomie modelu (abstrakcyjnie rzecz ujmując, pozbywam się pojęcia PHP), który przygotują zapytanie tylko do wykonania operacji na surowych danych, bez konieczności ich ewentualnego przeliczania. Oczywiście nie zawsze taki efekt da się uzyskać, ale należy to maksymalnie optymalizować.

Jedno jest wiadome: przeliczanie DATE() dla rekordów w warunku jest nieoptymalne dla pola DATETIME.

Dziś postaram się opisać, jakie kroki trzeba wykonać, aby bezpiecznie usunąć zdublowane rekordy z bazy danych nie tracąc żadnych danych:

1. Tworzymy dwie kopie bazy danych lub tabel, na których będziemy pracowali. Najlepiej, aby pracować na drugiej kopii, nigdy na oryginale, a potem wdrożyć zmiany z drugiej kopii na oryginał. Przezorny zawsze ubezpieczony.
2. Analiza danych w tabeli. Musimy dokładnie wiedzieć jakie są relacje między tabelami, kiedy występują JOIN’y itp. Jeżeli rekordy są zdublowane, a posiadają ustalony ID, do których odwołuje się inny rekord z sąsiedniej tabeli, trzeba będzie w niej zmienić ID rekord zdublowanego na ID “substytuta”, bądź takiego rekordu, który nie spowoduje zmian w serwisie.
3. Wykonanie operacji usunięcia zdublowanych rekordów.

Po wykonaniu kroku pierwszego zabieramy się za kolejny. Jest to najważniejszy moment naszych operacji. Aby ułatwić zrozumienie problemu, podam przykład z życia. Aplikacja posiadała poważny błąd, który umożliwiał zdublowanie użytkowników, ściślej: można było zdublować username. Za każdym razem, gdy użytkownik się logował i pisał komentarze, był ich właścicielem, ale comment_author posiadały różne ID tego samego użytkownika. Zaraz po skopiowaniu bazy danych spróbowałem przepisać ID autorów komentarzy na pierwszy rekord identyfikujący użytkownika, jaki istnieje w tabeli użytkowników. Skonstruowałem zapytanie:

UPDATE cms_comments
JOIN cms_members AS user_original ON(user_original.user_id = comment_author)
SET comment_author = (
  SELECT user_first.user_id FROM cms_members AS user_first
  WHERE user_first.user_name = user_original.user_name
  ORDER BY user_first.user_id ASC LIMIT 0, 1)

Usunięcie zdublowanych użytkowników było już tylko formalnością. Teraz się okaże, dlaczego zależało mi na wyciągnięciu dokładnie pierwszego rekordu reprezentującego “unikalnego” użytkownika: poniższe zapytanie (ALTER IGNORE TABLE ADD UNIQUE) usunie wszystkie kolejne rekordy oznaczone jako duplicated:

ALTER IGNORE TABLE cms_members ADD UNIQUE INDEX(user_name);

Krótki komentarz z manuala do ALTER TABLE:

IGNORE is a MySQL extension to standard SQL. It controls how ALTER TABLE works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. If IGNORE is not specified, the copy is aborted and rolled back if duplicate-key errors occur. If IGNORE is specified, only the first row is used of rows with duplicates on a unique key, The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value.

Pisząc ostatnie posty związane z bazami danych, mam nadzieję, że komuś się przydadzą.

Badamy:

SELECT 1+2+3
>> 6

SELECT 1+2+NULL
>> NULL

SELECT COALESCE( NULL, 0 )
>> 0

Zatem analogicznie do powyższego przykładu:

UPDATE users SET user_points = user_points + COALESCE((SELECT SUM( ... ) WHERE ...), 0)

Punkty użytkownika już zawsze będą się sumowały poprawnie :-)

1. Zebrać potrzebne dane za pomocą SELECT‘a, co sprawiłoby, że zajęta zostanie niepotrzebna pamięć w środowisku PHP podczas przypisania rezultatu do zmiennej.
2. Wykonać SET z podzapytaniem, ale potrzebnych mi było kilka kolumn z sąsiedniej tabeli, podzapytanie może zwrócić tylko jedną określoną wartość.
3. Wykonać JOIN przy update, czego niestety wówczas nie potrafiłem zrobić.

Kartkując manual nie natrafiłem się w standardowej dokumentacji na nic konkretnego, aż nie spojrzałem na bardzo przydatne komentarze użytkowników. Okazało się, że przy UPDATE można wykonywać dowolne JOIN‘y, schemat jest następujący:

UPDATE TABLE JOIN another_table SET ...

W tym momencie mamy do dyspozycji wszystkie pola z dołączonej tabeli. Bardzo przydatne.

Przykład z życia.

Miałem za zadanie odznaczyć typy bukmacherskie na trafione, nietrafione, odwołane z przyczyn odwołania całego meczu piłkarskiego oraz te, które jeszcze nie mogą zostać oznaczone jako trafione lub nie, gdyż mecz się jeszcze nie odbył.

UPDATE typer_tickets_items
LEFT JOIN typer_events ON(event_id = item_event)
SET item_status = (
CASE
WHEN event_status IS NULL THEN NULL # mecz nie zostal rozegrany
WHEN event_status = -1 THEN -1 # mecz anulowany
WHEN event_status = item_bet THEN 1 # typ trafiony
ELSE 0 END # typ nietrafiony
) WHERE item_status IS NULL

Mam nadzieję, że komuś się przyda…

CASE Syntax:

Najprostsza struktura CASE’aprzedstawia się nastepująco:

CASE WHEN [conditions] THEN ... ELSE ... END

Składnia powinna rozpocząć się słowem kluczowym CASE, a zakończyć END. Pomiędzy znajdują się warunki WHEN oraz operacja zwrócenia odpowiedniej wartości, która po nich następuje THEN (mamy możliwość uwzględnić nieskończenie wiele warunków). Jeżeli żaden warunek nie zostanie spełniony możemy użyć opcjonalnie ELSE.

Przykłady z życia.

Wyobraźmy sobie, że mamy posortować listę aukcji przedmiotów na Allegro od najtańszych, do najdroższych. Należy założyć, że są 2 typy aukcji: kup teraz i licytacja. Pole licytacji w bazie danych zawiera największą zaproponowaną kwotę przez użytkowników w procesie licytacji, a cena kup teraz ustalana jest przez sprzedającego. Są to dwa różne pola w bazie danych, a jedno kryterium sortowania, dlatego trzeba scalić cenę w jedną, wybierając odpowiednią. Musimy przewidzieć sytuację, w której aukcja jest typu kup teraz oraz licytacji, wówczas jeżeli najwyższa oferta jest większa od ceny kup teraz, wówczas wybieramy pole z największa propozycją:

SELECT (
  CASE
    WHEN (auction_type = 'bidding' OR auction_price_bid > auction_price_buynow)
      THEN auction_price_bid
    ELSE auction_price_buynow
  END) AS auction_price

Stworzyliśmy pole auction_price, po którym można sortować aukcje od najtańszej do najdroższej i na odwrót.

Mam nadzieję, że krótki wpis przyda się początkującym. Nic więcej nie trzeba opisywać, temat wydaje się co najmniej trywialny.

1. Sprawdzanie daty ostatniego postu na całym forum danej grupy. Pomysł zaczerpnięty z portalu nasza-klasa.pl, gdzie bok relacji użytkownik->forum zapisywana jest data ostatniego odwiedzenia forum. Jeżeli na forum jest nowszy post niż zapisana data – forum jest oznaczone jako nieprzeczytane. Minusem tego rozwiązania jest to, że działa bardzo ogólnikowo (nie wiadomo które tematy są nieprzeczytane, które nie – oznaczane jest tylko forum, w dodatku jeden raz).
2. Korzystanie z historii przeglądarki przy użyciu stylu a:visited. Plus – łatwość implementacji, minusy – ogólnikowe, nie zawsze zadziała, amatorszczyzna (nie na taki projekt, rozumiem blog).
3. Sposób z PHPBB: stworzenie relacji user->temat, gdzie zapisana jest data ostatniego czytania tematu. Plusy: możemy stwierdzić ostatnią wizytę co do konkretnego posta. Minusy: dużo syfu w bazie danych, wypadałoby dodać limit, np czyszczenie nieprzeczytanych for po ilości wątków oraz limit czasowy, czyszczone cronem lub przy innej okazji.

Po dłuższej analizie, zdecydowałem się na implementację trzeciego rozwiązania za pomocą tabeli:

• handle_user (id usera),
• handle_group (id grupy),
• handle_thread (id tematu),
• handle_time (czas ostatniej wizyty w temacie, defaultowo 0).

http://example.com/nazwa-produktu.html

Oczywiście można to objeść podając ID produktu i kategorii w adresie:

http://example.com/6521,nazwa-produktu.html

Chcemy tego uniknąć. Jak zatem rozwiązać problem zdublowania? Przed rozpoczęciem działań stwórzmy sobie mały plan działania:

• Zamiana tytułu newsa ze zwykłego na SEO friendly.
• Pobranie tytułów newsów pasujących do wzorca: LIKE ‘nasz-tytul%’.
• Dodanie sufiksu do tytułu -2 (jeżeli istnieje -2 wówczas -3), tak aby powstał nasz-tytul-2, nasz-tytul-3 w przypadku powtórzeń.

Krok 1. Stworzenie tytułu SEO friendly (listing).

Krok 2. Pobranie podobnych tytułów z bazy danych (listing).

Krok 3. Dodanie sufiksów do tytułów, jeżeli istnieją podobne, które uniemożliwiają dodanie rekordu (listing).

Teraz zmienna $sRewrite zawiera tytuł SEO, który możemy śmiało wpisać do bazy danych – na pewno sie nie powtórzy :)

Note: Przykłady zostały opisane na bazie mojego frameworka Vframe używając klasy Vframe_Util_Rewrite z której można skorzystać.

Wysłanie prostego powiadomienia to zwykłe przypisanie wiadomości do jego ID, natomiast gdy wysyłamy powiadomienia np o dodanym przez naszego przyjaciela materiale, nie będziemy przecież wysyłać po 1000 rekordów tylko po to, żeby każdy przyjaciel otrzymał informację. Robimy to w inny sposób: nadajemy ownera (notice_owner) powiadomienia na 0 i ustawiamy dodatkowe pole notice_self na 1. To oznacza, że powiadomienie tyczy się wszystkich użytkowników, którzy mają daną osobę w znajomych (stąd owner 0). Pole unotice_user informuje na temat kogo jest powiadomienie, a pole notice_type (int 2) nadaje numerek typu powiadomienia

[ struktura takiej bazy ].

Pora za zapytania. Najlepiej jakby wykorzystać wszystkie klucze zawarte w tabeli. Trzeba by było wykonać 2 zapytania, które zaznaczyłyby wszytskie rekordy. Z pomocą przychodzą nam unie [ zobacz zapytanie ].

Drugi sposób. Zamiast rozdzielania warunków na 2 zapytania możemy połączyć go w jeden operatorem OR. I tutaj jest problem. Jakiego bym klucza nie zrobił, żaden nie zostanie użyty [ zobacz zapytanie ].

Zdania są podzielone co do używania obu sposobów. Zadałem już pytanie na forum.php.pl, jednak nikt nie pokusił się na nie odpowiedzieć.

No nic, problem będzie nękał mnie nadal, aż przejdę do testów na sztucznie stworzonej bazie danych.