1. Brak zrozumienia

Powszechną pułapką, w którą często wpadają niedoświadczeni programiści, gdy mają do czynienia z bazami danych, jest brak pełnego zrozumienia złożoności ich działań. Znajomość składni języka SQL lub sposobu wykonywania złączeń to oczywiste punkty na liście kontrolnej niezbędnych umiejętności. Czasami jednak za tymi umiejętnościami nie idzie zrozumienie, w jaki sposób zapytania wpływają na bazę danych jako całość. Bez solidnego zrozumienia, programiści mogą nieświadomie pisać zapytania, które są nieefektywne lub nawet szkodliwe.

Sedno problemu często leży w braku szczegółowej wiedzy na temat tego, jak bazy danych zarządzają danymi, jak różne polecenia SQL wpływają na wydajność i jak działa prawidłowe indeksowanie. Co więcej, płytkie zrozumienie schematu baz danych może prowadzić do nadmiarowego lub nieprawidłowego pobierania danych. To nie tylko spowalnia działanie bazy danych, ale może również prowadzić do nieprawidłowej analizy danych, wpływając na decyzje biznesowe.

2. Korzystanie z przestarzałych porad

Na szczęście za każdym razem, gdy potrzebna jest porada, początkujący programista ma do dyspozycji całe 2,25 miliarda stron (nawet więcej, biorąc pod uwagę, że liczba ta była prawdziwa w 2022 roku). Jednak przy wszystkich tych informacjach wokół nas, a właściwie dlatego, że jest ich tak wiele, niektóre z nich są przestarzałe. To, co działało dekadę temu, może nie być obecnie najlepszym podejściem ze względu na postęp w systemach zarządzania bazami danych, zmiany w najlepszych praktykach i ulepszenia możliwości sprzętowych.

Na przykład niektóre wskazówki dotyczące optymalizacji SQL, które kiedyś były niezbędne do poprawy wydajności, takie jak ręczne tworzenie indeksów dla każdej operacji łączenia, mogą być teraz automatycznie obsługiwane przez bardziej zaawansowane silniki baz danych. Sztywne trzymanie się tych starych metodologii może prowadzić do marnowania wysiłku i nieoptymalnej wydajności, zwłaszcza gdy nowsze wersje baz danych automatycznie optymalizują te procesy.

3. Brak planu wdrożenia

Wprowadzanie zmian w bazie danych bez planu wdrożenia jest jak podróż bez mapy, telefonu, a nawet jasnego celu podróży – jest to ryzykowne, i prawdopodobnie nie skończy się dobrze. Niedoświadczeni programiści często popełniają błąd, pędząc do modyfikacji bazy danych z entuzjazmem, ale bez ustrukturyzowanego planu, co prowadzi do zmian, które mogą powodować więcej chaosu niż poprawy.

Wdrażanie zmian obejmuje znacznie więcej niż tylko poprawienie odrobiny SQL tutaj lub dodanie indeksu tam. Bez jasnego planu zmiany te mogą zakłócić działanie usługi, uszkodzić dane lub wprowadzić nowe błędy do systemu, który wcześniej działał dobrze.

4. Brak planu weryfikacji zapytań

Niedoświadczeni programiści często wdrażają zapytania bezpośrednio w środowiskach produkcyjnych bez odpowiedniej weryfikacji, zakładając, że jeśli zapytanie działa bez błędów, to musi być poprawne i wydajne. Takie podejście może prowadzić do poważnych problemów, w tym wąskich gardeł wydajności, nieprawidłowego pobierania danych, a nawet przestojów systemu, z powodu niesprawdzonych lub nieprawidłowo przetestowanych zapytań wprowadzanych do środowisk rzeczywistych.

Pominięcie weryfikacji zapytań pomija kluczowy krok w zapewnieniu, że działają one poprawnie w rzeczywistych warunkach operacyjnych i działają wydajnie w typowych scenariuszach obciążenia. Bez tego etapu, zapytania, które wydawały się nieszkodliwe w kontrolowanym środowisku programistycznym, mogą zachowywać się nieprzewidywalnie lub stać się problematyczne, gdy zostaną poddane presji w świecie rzeczywistym.

5. Brak planu wycofania

Znaczącym niedopatrzeniem, które wszyscy widzieliśmy więcej niż raz czy dwa, jest brak planu wycofania zmian w bazie danych. Bez jasnej strategii przywracania zmian wprowadzonych w bazie danych, nie ma żadnej siatki bezpieczeństwa, jeśli coś pójdzie nie tak. Może to prowadzić do przedłużających się przestojów i rozbieżności danych, a także komplikować proces odzyskiwania danych.

Na przykład, jeśli nowa kolumna zostanie dodana do bazy danych i nieumyślnie zakłóci działanie innych funkcji bazy danych lub migracja danych doprowadzi do ich utraty lub uszkodzenia, brak planu wycofania oznacza, że nie ma szybkiego sposobu na przywrócenie porządku. Rezultatem mogą być zakłócenia operacyjne i pilne, często chaotyczne wysiłki mające na celu naprawienie problemów bez narażania integralności danych.

6. Brak weryfikacji wydajności w skali

Niedoświadczeni programiści często pomijają znaczenie weryfikacji wydajności bazy danych w skali. Zpytanie lub system może działać bezbłędnie pod niewielkim obciążeniem kilku przypadków testowych. Mmoże się jednak załamać, gdy zostanie poddany pełnej wadze rzeczywistego użytkowania. Nieprzetestowanie działania systemu pod oczekiwanym obciążeniem operacyjnym może prowadzić do poważnych problemów. Potencjalne konswekwencje to m.in tym powolne czasy reakcji, limity czasu i awarie transakcji, gdy system zostanie ostatecznie wdrożony.

Dlaczego więc decydują się nie przeprowadzać testów?

• Nadmierna wiara w wydajność kodu
• Napięte terminy
• Ograniczone zasoby
• Niedoszacowanie wpływu obciążenia

7. Brak komunikacji

Bądźmy szczerzy, większość ludzi, którzy zajmują się programowaniem, nie robi tego z powodu wrodzonego zamiłowania do rozmów z ludźmi. Często programiści są przyciągani do tej dziedziny z miłości do kodu, rozwiązywania problemów i być może cichego skupienia, którego wymaga. Jednakże, jeśli chodzi o zarządzanie i rozwijanie baz danych w firmie, braz rozmów nie jest dobrym pomysłem. Utrzymywanie zamkniętych linii komunikacyjnych może prowadzić do odizolowanych wysiłków, nadmiarowej pracy i utraconych możliwości wykorzystania zbiorowej wiedzy.

Kiedy masz pokój pełen ludzi próbujących znaleźć rozwiązanie, nie rozmawiając ze sobą, mogą oni albo spędzić godziny, może dni, zastanawiając się nad tym w pojedynkę – albo rozpocząć rozmowę, rzucić kilka pomysłów i być może rozwiązać je razem w ułamku tego czasu.

8. Niezdefiniowana SLA lub linia bazowa

Posiadanie lub brak jasnej umowy o gwarantowanym poziomie świadczenia usług (SLA) lub linii bazowej wydajności może stanowić różnicę między przewidywalnym, zoptymalizowanym systemem a jego abominacją.

Brak jasnego poziomu bazowego wydajności lub umowy SLA oznacza, że nie ma uzgodnionego punktu odniesienia do oceny wydajności lub szybkości reakcji systemu. Ten brak jasności może prowadzić do nieporozumień między programistami a klientami lub między samymi członkami zespołu. Ciężko jest wtedy bowiem zgodzić się co do tego, czy system działa odpowiednio. Przykładem może być sytuacja, w której zapytanie do bazy danych zwraca wyniki w ciągu dwóch sekund – czy to wystarczająco szybko? Bez benchmarków lub celów wydajnościowych odpowiedź na takie pytanie może okazać się niemożliwa.

Nie wspominając już o tym, że bez dobrze zdefiniowanych oczekiwań optymalizacja wydajności systemu staje się ruchomym celem. Programiści mogą nie wiedzieć, które aspekty systemu należy traktować priorytetowo w celu poprawy lub jak skutecznie alokować zasoby. Może to skutkować marnowaniem wysiłku na coś, co ma niewielki wpływ na zadowolenie użytkowników lub cele biznesowe.

9. Utrata danych diagnostycznych w Oracle

Domyślnie systemy Oracle są ustawione na usuwanie logów diagnostycznych po ośmiu dniach. Niedoświadczeni programiści mogą zostać wprowadzeni w zaskoczenie przez to domyślne ustawienie, prowadząc do potencjalnego braku danych. Danych, które mogą być kluczowe dla diagnozowania problemów lub zrozumienia trendów wydajności w czasie.

Dlaczego ma to znaczenie? Dane diagnostyczne w bazach danych, takich jak Oracle, zawierają krytyczne informacje: dzienniki błędów, historie wykonania i wskaźniki stanu systemu itp. Dane te są nieocenione przy cofaniu się do operacji bazy danych w celu wskazania, gdzie coś mogło pójść nie tak. Odgrywają one również istotną rolę w dostrajaniu bazy danych w celu uzyskania idealnej, optymalnej wydajności w oparciu o wcześniejszą aktywność.

10. Brak całościowej wizji

Wreszcie, zbyt łatwo jest skupić się na natychmiastowych zadaniach lub krótkoterminowych celach, nie biorąc pod uwagę szerszego wpływu ich pracy na system jako całość. Zdolność do patrzenia dalej przychodzi wraz z doświadczeniem, a brak holistycznej wizji może prowadzić do fragmentarycznego podejścia. W takich przypadkach poszczególne komponenty są rozwijane lub optymalizowane bez względu na to, jak pasują do większego projektu. Rezultatem jest system, który może funkcjonować w częściach, ale brakuje mu spójności i skalowalności jako całości.