O dobry Boże, myślę, że widziałem je wszystkie. Najczęściej jest to próba naprawienia problemów z wydajnością przez kogoś, kto jest cholernie leniwy, aby znaleźć przyczynę tych problemów z wydajnością, a nawet zbadanie, czy rzeczywiście występuje problem z wydajnością. W wielu z tych przypadków zastanawiam się, czy nie jest to tylko przypadek osoby, która chce wypróbować konkretną technologię i rozpaczliwie szuka gwoździa pasującego do jej błyszczącego nowego młotka.
Oto ostatni przykład:
Architekt danych przychodzi do mnie z wyszukaną propozycją pionowego podziału tabeli kluczy w dość dużej i złożonej aplikacji. Chce wiedzieć, jakiego rodzaju wysiłki rozwojowe byłyby konieczne, aby dostosować się do zmiany. Rozmowa przebiegała tak:
Ja: Dlaczego to rozważasz? Jaki problem próbujesz rozwiązać?
On: Tabela X jest zbyt szeroka, dzielimy ją na partycje ze względu na wydajność.
Ja: Dlaczego myślisz, że jest za szeroka?
On: Konsultant powiedział, że to o wiele za dużo kolumn w jednej tabeli.
Ja: A to wpływa na wydajność?
On: Tak, użytkownicy zgłaszali sporadyczne spowolnienia w module XYZ aplikacji.
Ja: Skąd wiesz, że szerokość stołu jest źródłem problemu?
On: To jest tabela kluczy używana przez moduł XYZ i ma około 200 kolumn. To musi być problem.
Ja (wyjaśnienie): Ale moduł XYZ w szczególności wykorzystuje większość kolumn w tej tabeli, a kolumny, których używa, są nieprzewidywalne, ponieważ użytkownik konfiguruje aplikację tak, aby wyświetlała dane, które chcą wyświetlić z tej tabeli. Jest prawdopodobne, że w 95% przypadków i tak połączylibyśmy wszystkie stoły razem, co zaszkodziłoby wydajności.
On: Konsultant powiedział, że jest za szeroki i musimy to zmienić.
Ja: Kim jest ten konsultant? Nie wiedziałem, że zatrudniliśmy konsultanta, ani w ogóle nie rozmawiali z zespołem programistów.
On: Cóż, jeszcze ich nie zatrudniliśmy. Jest to część propozycji, którą zaoferowali, ale nalegali, abyśmy ponownie zaprojektowali tę bazę danych.
Ja: Uh huh. Dlatego konsultant, który sprzedaje usługi ponownego projektowania baz danych, uważa, że potrzebujemy przeprojektowania bazy danych ....
Rozmowa trwała i trwała w ten sposób. Następnie ponownie przyjrzałem się tej tabeli i stwierdziłem, że prawdopodobnie można by ją zawęzić za pomocą prostej normalizacji bez potrzeby stosowania egzotycznych strategii partycjonowania. Okazało się to oczywiście kwestią sporną, gdy zbadałem problemy z wydajnością (wcześniej niezgłoszone) i wyśledziłem je według dwóch czynników:
- Brak indeksów w kilku kluczowych kolumnach.
- Kilku nieuczciwych analityków danych, którzy okresowo blokowali tabele kluczy (w tym te „zbyt szerokie”), wysyłając zapytania do produkcyjnej bazy danych bezpośrednio za pomocą programu MSAccess.
Oczywiście architekt nadal naciska na pionowe podzielenie stołu zawieszonego na „zbyt szerokim” metaproblem. Potwierdził nawet swoją argumentację, otrzymując propozycję od innego konsultanta ds. Baz danych, który był w stanie określić, że potrzebujemy poważnych zmian projektowych w bazie danych bez patrzenia na aplikację lub przeprowadzania jakiejkolwiek analizy wydajności.