Muszę wspomnieć o problemach z DRY w świecie relacyjnych baz danych. Bazy danych zaprojektowano tak, aby działały szybko i dobrze przy użyciu logiki opartej na zestawach i za pomocą zapytań sargable. Zasady DRY często powodują, że programiści piszą zapytania nie podlegające wymianie lub używają logiki Row-by-agonizing-Row do wykorzystania istniejącego kodu w wielu sytuacjach. DRY i optymalizacja wydajności są często sprzeczne, a w świecie baz danych wydajność jest zwykle o wiele ważniejsza niż utrzymanie. Nie oznacza to, że nie powinieneś w ogóle stosować zasad DRY, tylko powinieneś być świadomy tego, jak wpłynie to na ogólną użyteczność bazy danych. Deweloperzy aplikacji najpierw DRY, a po drugie wydajność, twórcy baz danych uważają, że najpierw integralność danych, po drugie wydajność, bezpieczeństwo danych (wydajność i bezpieczeństwo mogą zamieniać się miejscami w niektórych systemach).
Zauważyłem ogólnie, że im więcej warstw abstrakcji umieszczanych w bazie danych, tym wolniej się one stają. Nie twierdzę, że nie chciałem, aby osoby, które same projektowały programy baz danych, nie wykonały lepszej pracy, pozwalając programistom na korzystanie z DRY bez wpływu na wydajność bazy danych, ale nie projektuję oprogramowania bazodanowego na tym poziomie , więc być może konflikt między abstrakcją a wydajnością w bazie danych jest trudniejszy do rozwiązania niż przypuszczam. Musimy jednak współpracować z systemami, które są obecnie budowane. Możemy poprosić o lepszą implementację zasad DRY w przyszłych wydaniach, które nie spowodują także spadku wydajności (i z biegiem lat poprawiły się, ale nadal są problematyczne), ale w międzyczasie musimy rozważyć, czy DRY jest właściwym posunięciem dla tej bazy danych w tym czasie.
Ale często te same funkcje, które chcesz zastosować, aby zapewnić spełnienie zasady DRY, powodują ogromne problemy w bazie danych. Nie twierdzę, że nigdy nie używaj SUCHEGO, ale nie przesadzaj z tym.
Przykłady tego, o czym mówię. Raz w miesiącu musisz wykonać import danych w wysokości miliona rekordów. Rekordy można już ręcznie dodawać poprzez interfejs użytkownika wywołujący zapisany proc. Ten proces, ponieważ został zaprojektowany do importu pojedynczych rekordów, dodaje tylko jeden rekord na raz. Używając DRY, aby uniknąć umieszczania kodu wstawiania w dwóch miejscach, piszesz kursor, aby wielokrotnie wywoływać proc, zamiast pisać importów opartych na zestawie, których potrzebujesz. Czas na import trwa od 30 minut, które zajęłoby przy użyciu logiki opartej na zestawie, do 18 godzin. Teraz właściwym sposobem na przestrzeganie DRY w tym przypadku byłoby naprawienie proc w celu obsługi importu wielu rekordów. Niestety często jest to niemożliwe lub bardzo trudne, aby wysłać tablicę do proc (w zależności od zaplecza db) i zmieniając proc, kończy się uszkodzenie aplikacji.
Funkcje skalarne i funkcje o wartościach przechowywanych w tabeli są również używane do implementacji zasad DRY i ponownie mogą poważnie wpłynąć na wydajność, szczególnie jeśli trzeba ich używać w sposób, który uniemożliwia wykorzystanie indeksów.
Widoki są również dobre do implementacji DRY. Jeśli jednak zaimplementujesz DRY za pomocą widoków wywołujących widoki wywołujące inne widoki, szybko dojdziesz do punktu, w którym zapytania przekroczą limit czasu pod obciążeniem. W rzeczywistości możesz potrzebować wygenerować zestawy danych milionów rekordów, gdy potrzebujesz tylko trzech na końcu. Tak więc jednopoziomowy widok złożonego zestawu połączeń do implementacji DRY może być doskonały (mam taki sam, którego używamy, aby upewnić się, że wszystkie sprawozdania finansowe używają tego samego podstawowego zestawu tabel i obliczeń niektórych rzeczy), więcej niż dwa poziomy i musisz rozważyć, czy tworzysz bałagan wydajności.