Mają rację. Łączenie w polu tekstowym CHAR(30) – szczególnie w polu zawierającym dane osobowe – będzie powolne, rażąco nieefektywne i niezwykle delikatne. Ludzie zmieniają swoje imiona (małżeństwo jest oczywistym przykładem), a wiele osób może mieć to samo imię.
Chcesz utworzyć odpowiednie indeksy w tabelach, aby obsługiwać kolejność, w której mają się pojawiać dane, i zapomnieć o klastrowaniu. Twoja procedura optymalizacji wydajności brzmi jak katastrofa szukająca miejsca, w którym może się wydarzyć. Przepraszamy, ale upuszczanie/tworzenie takich tabel to proszenie się o kłopoty.
Zacząłbym od UNIQUE INDEX na customer.id, UNIQUE INDEX na transaction.ticket_number i INDEX (dla wydajności, a nie kardynalności, więc egzekwowanie wyjątkowości nie jest strasznie ważne) dla transakcji (id, ticket_number DESC) i wziąłbym go z tam. Dane są zwracane z tabeli transakcji w kolejności, w jakiej pojawiają się w indeksie.
Rozważałbym grupowanie tylko wtedy, gdy wszystkie inne możliwości optymalizacji zapytań zostałyby wyczerpane.
