Są takie sytuacje gdy wymagane jest wykonanie szybkiego wsadu danych do tabeli. Oczywiście można na prędce stworzyć odpowiedni skrypt PhP, który przetworzy dane wsadowe do postaci zapytań SQL. Jednak nie zawsze ma to uzasadnienie i nie zawsze ilość czasu jest wystarczająca na stworzenie takiego mechanizmu.

Właśnie w takich sytuacjach przydatna może być kombinacja dwóch narzędzi: phpMyadmin i … to nie żart Ms Excel. Arkusz kalkulacyjny posłuży nam jako narzędzie do preparowania odpowiednio sformatowanego pliku CSV. Phpmyadmin posłuży nam natomiast do wykonania natychmiastowego wsadu do bazy.

Na potrzeby tego tutorialu stworzę wirtualną potrzebę wykonania wsadu do tabeli o poniższym wyglądzie

id_kw (int) AUTO_INCREMENT
name (varchar)
cond (int)

Jako wsad wykorzystany będzie plik xls zwierający kilkaset słów kluczowych.
W pierwszej kolejności wymagane jest odpowiednie sformatowanie pliku xls, do takiej postaci odzwierciedlającej strukturę tabeli. Pierwsza kolumna musi pozostać pusta – jest to kolumna odpowiadająca polu identyfikatora id_kw. W trzeciej kolumnie możemy dodać wartość początkową pola cond, lub pozostawić ją pustą w przypadku, gdy w strukturze tabeli określona jest wartość domyślna. Ja pozostawiam to pole puste.

Kolejnym etapem jest dodanie obrysu do wszystkich komórek arkusza odpowiadających wartościom pól tabeli. Zaznaczcie w Excelu „zawartość” tabeli a następnie zwykły obrys, efekt powinien być taki jak poniżej.

Na tym etapie może Was nieco dziwić to postępowanie jednak za chwilę zrozumiecie sens takiego działania. Zapiszcie bieżącą postać jako plik csv rozdzielany przecinkami (czytajcie uważnie pytania zadawane przez Excel i odpowiadajcie mądrze :D).

Otrzymany plik otwórzcie za pomocą jakiegoś edytora (najlepiej takiego który pozwala kontrolować kodowanie znaków). Pierwsze co pewnie zauważycie to fakt, że CSV rozdzielany przecinkami … jest rozdzielany średnikami (szczegół ). Obrysowanie dodatkowej pustej kolumny spowodowało, że po słowach kluczowych pojawił się dodatkowy średnik, który odpowiada polu cond.

Plik w obecnej postaci nie pozwoli Wam wykonać prawidłowego wsadu, jego kodowanie jest w ANSI. Przy bazie danych z kodowaniem UTF spowoduje oczywiście błędne wyświetlanie polskich krzaczków. Zmieńcie kodowanie znaków w pliku i zapiszcie go ponownie.

Przejdźmy teraz do phpMyadmina w którym wykonamy właściwy import danych. Wybierzcie odpowiednią tabele z bazy danych a następnie naciśnijcie zakładkę Import. W polu format wybierzcie CSV. Następnie musicie zmienić dolne opcje – Kolumny oddzielone: ustawcie ; . Pozostałe opcje możecie zostawić bez zmian. Naciśnijcie przycisk wykonaj … tabela zostanie wypełniona danymi. I gotowe … prawda, że szybko!

Kilka lat temu w MySQL domyślnym typem tabel był MyISAM i chociaż InnnoDB było wtedy już dostępne to jednak niewiele osób korzystało z tego rozwiązania. Szkoda, bo mimo pewnych wad, niewątpliwą zaletą InnoDB jest możliwość zrzucenia utrzymywania integralności danych na MySQL’a. Poświęcając odpowiednią ilość czasu na wykonanie prawidłowego projektu relacyjnej bazy danych opartej na tabelach typu InnoDB, nie będziemy tracić czasu na kodowanie odpowiednich metod utrzymujących integralność danych w bazie.

Jedną z podstawowych zalet mechanizmu składowania InnoDB, której nie posiada MyISAM to możliwość definiowania kluczy obcych w tabelach. W przypadku MyISAM klucze obce mogły być jedynie indeksowane, co oczywiście wpływało na na szybkość wykonywania zapytań jednak nie miało przełożenia na utrzymywanie integralności danych. Osobiście uważam, że w obecnej chwili poza wyjątkowymi sytuacjami praktycznie nie ma uzasadnienia by w swoich projektach wciąż kurczowo trzymać się MyISAM. Część osób w tym momencie powie, że InnoDB nie ma wyszukiwania pełno-tekstowego (Full-text search indexes) … no cóż od wersji 5.6.4 już ma, więc jeśli dysponujesz taką lub wyższą wersją MySQL, to wtedy pada ostatni bastion by nie używać InnoDB.

Warto zauważyć, że w przypadku istniejących tabel, zmiana mechanizmu składowania nie wymaga ponownego tworzenia tabel. Zmianę można dokonać wykonując poniższe zapytanie:

ALTER TABLE `nazwa_tabeli` ENGINE = InnoDB

Metodę definiowania kluczy obcych opiszę na podstawie przykładów opartych na poniższym schemacie ERD prostej bazy danych:

Baza składa się z dwóch tabel w których przechowywane są dane oraz jednej tabeli asocjacyjne, która je wiąże ze sobą. Po utworzeniu tabel i nadaniu odpowiednich indeksów na klucze można przejść do definiowania kluczy obcych.

ALTER TABLE `uzytkownik_typ` ADD FOREIGN KEY ( `id_uzytkownik` ) REFERENCES `uzytkownik` (`id_uzytkownik`) ON DELETE CASCADE ON UPDATE CASCADE ;

ALTER TABLE `uzytkownik_typ` ADD FOREIGN KEY ( `id_typ` ) REFERENCES `typ` (`id_typ`) ON DELETE CASCADE ON UPDATE CASCADE ;

I już! Dzięki tym prostym zabiegom uzyskaliśmy pełną integralność danych w bazie, oraz kaskadowe usuwanie rekordów. Oznacza to, że każdorazowe usunięcie rekordu z tabeli `typ` lub też `uzytkownik` spowoduje usunięcie wszystkich wystąpień kasowanego klucza obcego w tabeli `uzytkownik_typ`. Przykład:

DELETE FROM `uzytkownik` WHERE `uzytkownik`.`id_uzytkownik` = 1

Wykonanie powyższego zapytania spowoduje usunięcie z tabeli `uzytkownicy` rekordu o identyfikatorze 1. Mechanizmy bazy danych, dążące do utrzymania integralności danych w tabelach wykonaja jednak również usunięcie wszystkich typów przypisanych do kasowanego użytkownika. Usnięte zostaną wszystkie rekordy z tabeli `uzytkownik_typ` w których wartość klucza obcego `id_uzytkownik` są równe 1.

Analogiczna sytuacja będzie występować w przypadku zmiany wartości klucza głównego w tabeli, `uzytkownik` lub `typ`. Każda z takich zmian będzie kaskadowo przenoszona na tabelę asocjacyjną `uzytkownik_typ`.

Jedna uwaga odnośnie modyfikacji istniejących tabel. Sama zmiana mechanizmów składowania na InnoDB nie wymaga zachowania integralności, jednak zdefiniowanie kluczy obcych wymaga doprowadzenia tabel do porządku. Sytuacja gdy tabela będzie  zwiera rekordy w których występują klucze obce, których nie ma w macierzystej, spowoduje zablokowanie możliwości ich zdefiniowania. W takich przypadkach przed definiowaniem kluczy obcych, dane w tabeli muszą być w pełni uporządkowane względem pozostałych tabel. Musisz samodzielnie przeprowadzić integrację tabel.

W zależności od zawartości pola WYNIK test traktowany jest jako zapisany (wartość NULL) lub wysłany (wartość liczbowa decimal z uzyskanym wynikiem). W ostatnim czasie spotkałem się z dziwnym zachowaniem tego mechanizmu testów punktowanych. Korzystając z formularza otwartego w kilku oknach, można było nadpisać pierwotnie wysłane dane z odpowiedziami testu. Błąd ten wynikał z faktu, że mechanizm nie rozpoznawał w prawidłowy sposób statusu wysłanego testu. Było to o tyle dziwne, że patrząc od strony rekordów znajdujących się w bazie danych wyglądało to całkowicie prawidłowo.

Za brak prawidłowego rozpoznania odpowiedzialny był MySQL, dla którego wartość pola WYNIK = NULL jest równoważne z wartością pola WYNIK = 0.00.

W celu sprawdzenia statusu danego testu wykonywane było sprawdzenie liczby rekordów zwracanych przez poniższe zapytanie:
SELECT *FROM `test`
WHERE `id_uzytkownika` =1
AND `punkty` != NULL
w obu przypadkach zwróci ten sam wynik, czyli 0 rekordów.

Sposób na szybkie sprawdzenie rzeczywistego statusu testu to pobranie rekordu danego użytkownika a następnie sprawdzenie wartości pola już po stronie PHP. Można to zrealizować choćby w ten sposób:

$test_wyslany=0;
if (!empty($test['WYNIK'])) {
$test_wyslany=1;
}

$test – tablica z wynikiem powyższego zapytania SQL

Ot taka ciekawostka ze styku programowania i właściwości baz danych.
ddd