W pracy wzięliśmy się za przerzucanie danych z bazy MySQL do MSSQL aby dane były widoczne na nowym portalu. Stara baza i portal były pisane przez firmę zewnętrzną.
I tutaj zaczynają się schody. W zasadzie tyle schodów, że można by śpiewać "Stairway to heaven".
-
Baza jest 2-językowa. Tak na równi 50% nazw jest angielskich, a 50% polskich. Są tabele nazwane po angielsku, mające pola po polsku, i odwrotnie.
-
Nie ma praktycznie żadnych relacji pomiędzy tabelami. Wszystkie dane są ściągane przez skrypty PHP a później łączone.
-
Z województwami to są dopiero cyrki. W każdej tabeli id_woj jest innym typem, raz tinyIntem, raz Varcharem. Nie ma tabeli województwa z odpowiednimi Id, tylko w aplikacji jest stworzona tablica i po ściągnięciu z bazy id wyciąga się z tej tabeli dane województwo. Dodatkowo, aby zapewnić na pierwszym miejscu tablicy pole "wszystkie" (potrzebne do sortowania) to robią tak:
$wojew = getAllProvinces();
$wojew = array_reverse($wojew , true);
$wojew[0] = '-- wszystkie --';
$wojew = array_reverse($wojew , true);
-
Tabela oferta zawiera kolumnę 'id_zatrudnienia' i 'zatrudnienie'. To pierwsze w każdym rekordzie jest puste (na początku szukałem nawet odpowiedniej tabeli, gdyż patrzyłem na sam schemat bez danych). To drugie oznacza ilość osób zatrudnionych, jednak typ kolumny to Varchar, więc już widzę tą dodatkową robotę z parsowaniem w programie.
-
Kolumna branż jest typu Varchar, a kolejne Id są wpisywane po średniku - tak się wykonuje relację N-N.
-
Zapytanie do bazy o wyszukanie oferty ma 280 linii kodu.
-
Przeczesywałem całą bazę, a później kod programu żeby znaleźć, gdzie następuje mapowanie rodzaju oferty do inta. Dopiero po jakiejś godzinie szef powiedział, abym spojrzał do configa, bo oni tam podobno zmienne definiowali. I ukazał mi się plik mający ponad 300 linii z samymi definicjami zmiennych globalnych. Dodatkowo połowa zmiennych nazywana po angielsku, a połowa po polsku.
