De har rätt. Att gå med i ett CHAR(30) textfält - särskilt ett som innehåller personnamnsdata - kommer att vara långsamt, grovt ineffektivt och otroligt ömtåligt. Människor ändrar sina namn (äktenskap är det uppenbara exemplet), och flera personer kan ha samma namn.
Du vill skapa lämpliga index på dina tabeller för att stödja den ordning du vill att data ska visas i, och glömma klustring. Din prestandaoptimeringsprocedur låter som en katastrof som letar efter en plats att hända. Ursäkta, men att släppa/skapa tabellerna på det sättet ber om problem.
Jag skulle börja med ett UNIKT INDEX på kund.id, ett UNIKT INDEX på transaktion.biljettnummer och ett INDEX (för prestanda snarare än kardinalitet, så att upprätthålla unikhet inte särskilt viktigt) på transaktioner (id, biljettnummer DESC), och ta det från där. Data returneras från transaktionstabellen i den ordning den visas i indexet.
Jag skulle bara överväga klustring när alla andra vägar för frågeoptimering har uttömts.