Odejmowanie w MySQL’u wydaje się być proste. No bo jaka może być filozofia w odejmowaniu jednej liczby od drugiej, zwłaszcza że obie są typu INT? Jeden przypadek sprawił, że jednak wcale nie jest tak do końca oczywiste.
Załóżmy, że mamy w bazie dwie tabelki X i Y:
Chcielibyśmy w jednym zapytaniu zmniejszać kolumnę “stock” z tabeli Y o wartość “amount” z tabeli X. W sumie co to za filozofia? (zakładamy, że stock może być ujemny):
Zapytanie działa, cieszymy się, ale co w przypadku kiedy “amount” jest większy od “stock”? Okazuje się, że MySQL zamiast zapisać wartość ujemną do pola, które zdefiniowaliśmy jako SIGNED, przekręca licznik i wstawia nam 7-cyfrową wartość dodatnią! Powodem tej sytuacji jest bit znakowy, wykorzystywany w polach typu SIGNED i jego brak w polu typu UNSIGNED. Aby zapytanie działało dokładnie tak jakbyśmy tego chcieli, musimy użyć funkcji CAST i wtedy będziemy operować na dwóch identycznych typach.
Ot taka ciekawostka, której można się nie spodziewać, a jednak jak już się na to trafi, to wszystko wydaje się oczywiste :)
Ostatnio w jednym z naszych projektów potrzebowałem wyciągnąć z bazy produktów po jednym produkcie według item_code. Miałem listę tych kodów do wyciągnięcia, powiedzmy że obejmowały zakres od 1809 do 1820. Banał.
SELECT * FROM items WHERE item_code = 1809;
I niespodzianka - 3 wyniki, ich item_code’y to 1809, 1809CI, 1809S. Oczywiście wywaliło to od razu skrypt, bo zamiast tablicy asocjacyjnej z kolumnami dla jednego wiersza, dostałem tablicę 3-elementową, po jednym elemencie dla każdego wiersza.
Krótkie wytłumaczenie, jeżeli jeszcze się ktoś nie domyślił - akurat ta baza jest na tyle durna, że item_code to pole varchar a nie int. Więc jeżeli w warunku jest item_code = 1809 a nie item_code = ‘1809′, to MySQL rzutuje całą kolumnę na integery, przez co do porównania wywala litery z końca kodu i nagle pasują mu aż 3 wpisy. Podanie szukanego kodu w uszach jako stringu daje spodziewany jeden jedyny rekord z kodem 1809.
Więc tylko ku przestrodze - nie wyszukujcie integerów w kolumnach tekstowych!
Czasem nam się zdarza, że format daty na stronkach ma być bardziej poetycki niż YYYY-mm-dd.
Niby nie ma problemu, słowne formaty też przecież są dostępne. Ale co jeśli serwis jest wielojęzykowy, albo po prostu nie-angielski? Okazuje się że ludziki od MySQLa to przewidzieli i wszystko mamy podane na tacy :)
Wystarczy przestawić locales jednym zapytaniem i już mamy ładne opisowe daty wedle uznania, np dla norweskiego:
SET lc_time_names = ‘no_NO’;
Od tej pory SELECT DATE_FORMAT(NOW(), ‘%d. %M %Y’) AS date daje nam przyjemne dla oka (grafika, nie programisty) ‘23. oktober 2009‘. No, trochę lewy przykład, bo Norwegowie mają prawie identyczne nazwy miesięcy jak Angole, no ale przynajmniej już jest przez ‘k’ ;)
Więcej do poczytania i dostępne wartości lc_time_names są tutaj:
http://dev.mysql.com/doc/refman/5.0/en/locale-support.html
Posiadanie różnych wersji IE na tym samym profilu nie jest zbyt fajnym rozwiązaniem. Przykładowo IE6 potrafi sobie przejąć część zachowań z IE8, lub innymi słowy mówiąc to IE8 wkrada się w silnik IE6 przez co przeglądarka czasami zachowuje się w sposób nieobliczalny.
Przykładowo: chcę dołączyć (w
komentarzu warunkowym) arkusz styli przeznaczony tylko i wyłącznie dla IE6 (lub niższych). W kodzie wszystko jest poprawnie zapisane, a moje IE jakimś cudem nie łapie zmian. Okazało się, że musiałem zmodyfikować komentarz warunkowy na:
Po tym triku nasz arkusz zostaje załączony. Wychodzi na to, że IE6 renderuje całość wg swoich kryteriów, natomiast identyfikuje się jako IE8. Sprawa trochę kłopotliwa gdyż wprowadza trochę problemów podczas pisania kodu. Można to obejść, lecz trzeba pilnować aby przed wystawieniem na produkcję poprawić ten komentarz warunkowy.
Zamiast instalować kolejne wersje IE można skorzystać z aplikacji
IETester. Program oferuje odpalenie dowolnej strony przy pomocy jednej z wersji IE. Razem z nim jest zainstalowany Debug Toolbar, który potrafi być bardzo przydatny. Wadą tego programu jest to, że czasami potrafi w zadziwiający sposób wyświetlać niektóre strony przez co ciężko jest poprawiać jakiekolwiek błędy.
Myślę, że to najwyższa pora przyłączyć się do frontu likwidacji IE6 =)
Nakład pracy spowodował, że nieboraczka Natalia wpadła w sidła szaleństwa. Jedynie pies-egzorcysta może jej pomóc!
Pyczuś!
Mam przykładowo tablę, która pełni rolę licznika odwiedzin dla danego rekordu. Aby troszkę to utrudnić to ta tabela dodatkowo przetrzymuje informacje jakiego typu jest ten licznik. Oczywiście został ustawiony unikalny klucz typu id-typ. Taki licznik można inkrementować jednym zapytaniem:
Zapytanie jest raczej proste (jeśli nie wiesz co oznacza “ON DUPLICATE KEY”
odsyłam do manuala MySQL). Całość trochę się komplikuje kiedy jednym SQLem chcę wrzucić kilkanaście rekordów. W tej sytuacji nasze zapytanie zmienia formę na coś takiego:
Wpis ku pamięci.
Funkcja include() przydaje się w wielu sytuacjach. Jest też parę sztuczek i kruczków z tym związanych (o których mowa w manualu PHP).
Mój skrypt dzielił się na kilka akcji, odpalanych w jednej instancji po kolei. Pierwsza akcja wrzucała parę rekordów do bazy, a potem zapisywała ich ID do tablicy. Ta tablica natomiast była eksportowana do pliku w formacie:
Kolejna akcja wczytywała tą tablicę (za pomocą polecenia $arr = include(’data.php’);), dokonywała na niej modyfikacji i ponownie zapisywała w podobny sposób, do tego samego pliku.
Po uprzednim przygotowaniu danych (przez akcje I i II), akcja III ponownie ładowała ten plik. Tutaj niestety był błąd, bo użyłem include_once() zamiast include(). Efekt tego był taki, że include_once() nie zwrócił tej tablicy, a jedynie przekazał wartość logiczną TRUE.
Sprawiło mi to niemały problem, ponieważ akcja III się wysypała, z powodu złych danych w zmiennej, a debugowanie było dość uciążliwe (ciężko było znaleźć błąd). Oczywiście łatwo domyślić się dlaczego tak się stalo. Z tego też powodu uczulam na użycie funkcji include_once w kontekście zwracania zmiennych. Zamiast tego należy użyć include().
Jak wspomniałem, takie zachowanie wynika ze specyfikacji działania funckji include_once(). Wpis ku pamięci.
Dzisiaj odbyliśmy małą walkę z wysłaniem metodą POST tablicy wielowymiarowej. Problemem było to, że CURL konwertował tablicę typu:
do:
Najwyraźniej PHPowy CURL spłaszcza takie tablice, robiąc straszne zamieszanie :) Rozwiązanie jest dość banalne. Trzeba “ręcznie” spłaszczyć taką tablicę do formatu:
W ten sposób odebrane dane będą identyczne z tymi co wysłano.
Swego czasu miałem spory problem z rozwiązaniem problemu wyciągnięcia danych grupując i sortując jednocześnie.
Cały problem polegał na tym, że chciałem wyciągnąć najnowszego newsa z konkretnej grupy. Robiłem to mniej więcej tak:
Niestety wynik bywał opłakany, bo wyciągane były zazwyczaj newsy pierwsze z brzegu. Dlaczego? Otóż przed ORDERem następuje grupowanie. MySQL w tej sytuacji nie patrzy na to czy ma jakoś posortować dane, tylko najpierw grupuje, a potem coś tam próbuje posortować :)
Żeby rozwiązać ten palący problem spędziłem trochę czasu na poszukiwaniach w Sieci. Widziałem jakieś INNER JOINy z JOINami i innymi cudami. Rozwiązanie, które pokażę (a znalazłem przypadkiem :)) wykorzystuje podzapytanie. Całość wydaje się zgrabna i czytelna, chociaż przyznam, że nie sprawdzałem pod kątem wydajności.
Miałem za zadanie zrobić import jakiś danych o uzytkownikach z pliku tekstowego. Użytkowników w bazie już miałem (jakieś 50k rekordów), import miał za zadanie uzupełnić ich dane.
Parsowanie pliku było dość banalne. Poboierałem z niego dane (login i reszta danych), później pobierałem z bazy id usera (po loginie) i robiłem resztę rzeczy. Wszystko było super, aż do momentu odpalenia. Plik z danymi był spory, ale po pół godziny pracy import nadal się nie zakończył!
Zastanawiałem się jak to przyspieszyć. Przypomniała mi się rzecz, o której tyle razy przypominał Dooshek - użycie tablic. Na czym polega cały myk? Otóż na początku pobierałem wszystkie loginy i id userów i zapisywałem do tablicy w formacie [login] => [uid]. Podczas importu danych z pliku sprawdzałem id usera z tablicy przez co pół godzinny import wykonał się nagle w 30sek. :)
Warto o tym szczególe pamiętać. Ja już któryś raz z rzędu o tym zapomniałem, a szkoda. Straciłem trochę czasu na optymalizację mojego importu.
Przy zawrotnej liczbie rekordów pewnie nie będzie warto robić takiej tablicy (ponieważ zje zasoby :) ), ale przy jakiejś mniejszej liczbie myślę, że warto.
