Rozłożyłem swoją tabelę użytkowników na części i zaczynam składać zapytania aby działały na kilku tabelach jednocześnie, co nie będzie dla mnie łatwe, a wręcz przeciwnie bo ja laik jestem i się dopiero uczę. Przeczulony na punkcie optymalizacji czyli wydajnej architektury budowy bazy wpadłem na taki pomysł:
- a mianowicie zaczynając od rejestracji użytkownika i przechowywania jego loginu, hasła i adresu e-mail w tabeli, wymyśliłem, że adres e-mail jako ukryty dla użytkowników niepotrzebnie tylko zajmuje miejsce w tabeli głównej użytkownika, która to poddawana będzie przeszukiwaniu i postanowiłem zapisać go w odrębnej tabeli, razem z danymi które nie będą brane pod uwagę przy wyszukiwaniu. Natknąłem się na nie lada problem przy przebudowie zapytań, bo skoro adres e-mail będzie w osobnej tabeli, a id użytkownika dopiero utworzy się przez auto_increment to raczej nie jest możliwym (wedle mej oceny) w jednym zapytaniu zapisać login, hasło które to otrzymają swój id i jednocześnie w drugiej tabeli przypisany do nowo nadanego id zapisać rekord z adresem e-mail.
Na moją skąpą wiedzę mógłbym to zrobić w 3 zapytaniach, jednak 3 zapytania to o 2 więcej niż miałem dotychczas, a jeśli jest to możliwe to chciałbym tego uniknąć.
Wprawdzie wpadł mi do głowy taki dość ryzykowny pomysł, który to przedstawia się tak:
- w tabeli users id generuje się automatycznie i podczas zapisu nowego użytkownika przyjmie ono jakąś określoną wartość
- w tabeli dane (z e-mail) też ustawie auto_increment i teoretycznie oba id będą tej samej wartości
Jednak ja nie wiem czy mogę tak temu zaufać, bo jeśli coś się przestawi to...wszystko się pomiesza.
Jest możliwym osiągnąć synchronizację numerów id dwóch tabel lub też może jakiś inny sposób na zapis w 2 tabelach jednym zapytaniem?
A może niepotrzebne me obawy, że oba pola id z auto_increment się rozsynchronizują?

Po pierwsze: nie spotkałem się jeszcze z rozwiązaniem, żeby dane użytkownika rozbijać na dwie tabele. Nie wiem, czy faktycznie - tak jak ty myślisz - zapewniłoby to bazie lepszą optymalizację i wydajność. Może przy jakiejś kilkumilionowej liczbie rekordów dałoby się to odczuć (chociaż nie wiem, bo to tego co chcesz zrobić trzeba by wprowadzić relacje, a to też zawsze trochę obniża wydajność). Postawiłbym jednak na logikę i przejrzystość i skoro jest użytkownik - to wszystkie jego dane powinny spoczywać w jednym miejscu.

Po drugie: Jeśli już koniecznie chcesz coś takiego zrobić to na pewno nie twoim sposobem. Nie możesz polegać na auto incremencie, bo co jeśli kiedyś skasujesz dane w jednej tabeli, a w drugiej zapomnisz? Wszyscy użytkownicy, którzy się po tym zarejestrują "wymienią się" danymi ukrytymi (id będzie przesunięte). Musiałbyś więc wprowadzić relację typu jeden do jednego między tabelą z danymi o użytkowniku a tabelą z danymi ukrytymi (klucz obcy w tej drugiej tabeli, określający do którego użytkownika przynależy).

Na twoim miejscu jednak nie bawiłbym się w takie rozwiązania i ewentualnie zaindeksował w bazie te pola, które najczęściej pobierasz (np. nazwa użytkownika).