Witam,

Chciałem przekonwertować bazę danych z Lati2 do UTF-8 ale dobrze, że zastnowiłem się zanim to zrobiłem. Mam szereg tabel z polami id (auto_increment). Table są między sobą powiązane właśnie przez tą wartość. Np tabela przodek (pola id,osoba) jest powiązana z tabela osoby (id,imie,nazwisko), gdzie przodek.osoba=osoby.id. Stąd też moje pytanie. Czy jest jakaś możliwość skonwertowania bazy danych, żeby pola id zachowały swoją wartość? Jeśli wyeksportuję bazę danych do pliku, utworzę nową strukturę tabel w bazie danych w UTF-8 i wrzucę starą bazę to zmieni się zawartość pól id i wszystkie powiązania pomiędzy kilkunastoma tabelami można będzie wyrzucić do kosza. Aha, id nie mają kolejnych wartości (część rekordów była usuwana w międzyczasie).

Przy imporcie wyeksportowanych danych nie są zmieniane wartości w polach auto_increment. Nie obawiaj się, że stracisz relacje.

Niezupełnie.

MySQL pozwala zpisać do pola AUTOINCREMENT dowolną wartość typu UNSIGNED INT. AUTOINCREMENT generuje automatycznie nowe wartości tylko w przypadku gdy przy INSERT nie aktualizujemy pola o tym typie - w innym przypadku próbuje zapisać przekazane dane. Więc bez problemu możesz odtworzyć wszystkie dane zachowując wartości indeksów...
Ale jest pułapka - jeżeli na klucze obce w tabelach masz nałożone ograniczenia rodzaju ON UPDATE RESTRICT, to w czasie odtwarzania bazy nie pozwoli ci zapisać rekordów dla których jeszcze brakuje danych powiązanych... Dlatego najpierw należy wczytać wszystkie dane, a dopiero potem odtworzyć schemat relacji oraz pozakładac indeksy i ograniczenia...

Jest z tym trochę roboty, ale zadanie jest wykonalne. Powodzenia.

Nie za bardzo rozumiem o co chodzi z tą pułapką. Wszystkie tabele są mniej więcej o strukturze:
id(auto_increment),pole1(int),pole2(text),pole3(int),pole4(date). Jedynie w przypadku tabeli sesje mam dodane bodajże do pola time ON UPDATE CURRENT TIMESTAMP (czy coś w tym rodzaju). Oprócz tego mam indeksy: PRIMARY, no i na inne pola też. Tabele są więc raczej proste a relacje polegają jedynie na tym, że w polu np. pole3 tabeli tabela2, mam wpisaną wartosc id z pola pole2 tabeli1, które wykorzystuje przy poźniejszym pobieraniu i przetwarzaniu danych w php. Czy mogę więc spokojnie to wszystko przekonwertować, czy też uważać na ową pułapkę? (ewentualnie jeśli mam uważać) to jak to przeprowadzić, bo nie za bardzo chwytam

Skoro nie wiesz o co chodzi, to na 99% nie stosujesz tego mechanizmu, więc śmiało możesz przenosić dane.

Ale na wszelki wypadek wytlumaczę ci o co chodzi:
Załóżmy, że masz tabelę A o polach A_ID (klucz podstawowy) i B_ID (klucz obcy do tabeli B ),
oraz tabelę B z polem B_ID (klucz podstawowy).
W tabeli A na polu B_ID można założyć ograniczenie ON UPDATE RESTRICT co oznacza, że przy każdej zmianie zawartości tego pola baza sprawdza czy istnieje odpowiedni wpis w tabeli B. Jeżeli nie - polecenie UPDATE (albo INSERT) wygeneruje błąd.
Ten mechanizm pozwala zachować spójność danych w relacjach. A pułapka polega na tym, że jeżeli spróbujemy do pustej bazy najpierw zaimportować tabelę A a później tabelę B to ta operacja się nie uda...
Powodzenia.

Dziękuję za dotychczasową pomoc. Prosiłbym jeszcze o sprawdzenie zaplanowanej metodologii mojej konwersji. Całość tworzyłem 2 lata (pisanie kodu, tworzenie bazy danych). Chcę dokonać konwersji z prostego powodu... w Latin2 brakuje mi niektórych znaków, które mogą być potrzebne użytkownikom strony.
Tak więc planuję zrobić tak:
1. Wyeksportować strukturę i dane z bazy (do oddzielnych plików).
2. Pousuwać z wyeksportowanej struktury DEFAULT CHARSET=latin2
3. Stworzyć nową bazę danych w UTF-8
4. Zaimportować strukturę wskazując jako zestaw znaków dla pliku latin2
5. Zaimportować w ten sam sposób dane
6. Skonwertować pliki strony za pomocą Gżegżółki
7. Wrzucić nową stronę na serwer, zmienić dane bazy, dodać po połączeniu z bazą danych SET NAMES=UTF-8

Tak? Macie jakieś uwagi?

Podpowie ktoś, czy dobrze wykombinowałem?

wygląda logicznie i porawnie, brakuje tylko punktu 0 (zero) przed 1:

0. Zdrobić backup całej bazy (struktura+dane)

tak na wszelki wypadek - gdyby jednak coś poszło nie tak...
powodzenia.

Dzięki. Backup jest tak oczywisty, że go pominąłem