@Koziołek ad sytuacji.
Pierwsza sytuacja miała miejsce podczas konwersji walut. Mieliśmy tabelkę typu kod, kod, wartość, data. Chodziło o trzymanie wartości walut dla poszczególnych dat. I dalej przeliczanie z jednej wartości na drugą w odstępie czasowym. Początkowe założenie było takie że raz na dzień będą wpadać wartości i konwersja będzie per dzień. Indeks założony na 3 kolumny kod kod i data. kody stringowe. I o ile dla samego wyświetlania wartości w przedziale czasowym nie miało to większego znaczenia, o tyle przy konwersji konkretnych kwot w kolejnych tabelach czuć było spadek wydajności. Dodanie numerycznego id i zmiana PK na kolumnę z ID a nie na 3 połączone kolumny odsunęło konieczność realnej optymalizacji o kilka miesięcy.
Druga sytuacja zabawa z strukturą drzewiastą czyli struktura zatrudnienia i konkretna sprzedaż za kilka miesięcy,wykorzystanie connect by. Mamy w tabelce imię i nazwisko człowieka, mail i imię i nazwisko jego managera, mail managera. Łączyliśmy po emailach dla 4-5 stopniowej struktury zatrudnienia, każda osoba mogła sprzedawać, dane sprzedażowe z 3 systemów wpływały codziennie.
Dla ok 500k wpisów z systemów sprzedażowych to była totalna sieczka optymalizacyjna. Bywało że raport generował się 5 minut, w samej bazie podobnie. Tutaj niestety nie można było wrzucić pk numerycznego i jedyne co pomogło to widoki zmaterializowane. Optymalizacja odsunięta o kilka miesięcy, ale następne co będzie trzeba zrobić to partycjonowanie i podejrzewam że w ciągu najbliższego roku będzie trzeba to zrobić w systemie.
Co ciekawe klient na nas nie narzekał, o wiele wiele bardziej narzekał na system w którym ewidencjonowali sprzedaż taki na S. ;) I z tego co wiem bardzo ich cisnęli o to że działa coraz wolniej. Dodam że dało się to odczuć, w ciągu trzech miesięcy generowanie raportu sprzedażowego z tamtego systemu wydłużyło się o kilka minut. przy czym nie było aż tak dużo danych bo 500k rekordów to nie jest dużo.