Jakie są najczęstsze anty-wzorce SQL? [Zamknięte]

Wszyscy, którzy pracują z relacyjnymi bazami danych, nauczyli się (lub uczą się), że SQL jest inny. Uzyskanie pożądanych rezultatów i zrobienie tego wydajnie wymaga żmudnego procesu częściowo charakteryzującego się poznaniem nieznanych paradygmatów i odkryciem, że niektóre z naszych najbardziej znanych wzorców programowania nie działają tutaj. Jakie są typowe antypatterny, które widziałeś (lub sam popełniłeś)?

Konsekwentnie rozczarowuje mnie tendencja większości programistów do mieszania logiki interfejsu użytkownika w warstwie dostępu do danych:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Zwykle programiści robią to, ponieważ zamierzają powiązać swój zestaw danych bezpośrednio z siatką, a po prostu wygodnie jest mieć format SQL Server po stronie serwera niż format na kliencie.

Zapytania takie jak powyższe są wyjątkowo kruche, ponieważ ściśle łączą warstwę danych z warstwą interfejsu użytkownika. Ponadto ten styl programowania całkowicie uniemożliwia ponowne użycie procedur przechowywanych.

Oto moje 3 najlepsze.

Numer 1. Brak określenia listy pól. (Edycja: aby uniknąć nieporozumień: jest to reguła kodu produkcyjnego. Nie dotyczy to jednorazowych skryptów analitycznych - chyba że jestem autorem).

SELECT *
Insert Into blah SELECT *

Powinien być

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Numer 2. Używając kursora i pętli while, gdy wykona się pętla while ze zmienną pętli.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Numer 3. DateLogic poprzez typy ciągów.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Powinien być

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Widziałem ostatnio skok „Jedno zapytanie jest lepsze niż dwa, prawda?”

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

To zapytanie wymaga dwóch lub trzech różnych planów wykonania w zależności od wartości parametrów. Generowany jest tylko jeden plan wykonania i umieszczany w pamięci podręcznej dla tego tekstu sql. Ten plan będzie stosowany niezależnie od wartości parametrów. Powoduje to sporadyczne słabe działanie. O wiele lepiej jest napisać dwa zapytania (jedno zapytanie na planowany plan wykonania).

• Pola hasła czytelne dla człowieka , np. Wyjaśniające.

• Korzystanie LIKE przed indeksowanych kolumnach, a ja prawie pokusie tylko powiedzieć, jak w ogóle.

• Recykling wygenerowanych przez SQL wartości PK.

• Niespodzianka, nikt jeszcze nie wspomniał o boskim stole . Nic nie mówi „organiczne” jak 100 kolumn flag bitowych, dużych ciągów i liczb całkowitych.

• Następnie jest wzorzec „Tęsknię za plikami .ini” : przechowywanie plików CSV, ciągów rozdzielanych potokami lub innych wymaganych danych w dużych polach tekstowych.

• A w przypadku serwera MS SQL w ogóle korzystanie z kursorów . Jest lepszy sposób na wykonanie dowolnego zadania kursora.

Edytowane, ponieważ jest ich tak wiele!

Nie musisz za to głęboko sięgać: nie używaj przygotowanych instrukcji.

Używanie bez znaczenia aliasów tabeli:

from employee t1,
department t2,
job t3,
...

Sprawia, że ​​czytanie dużej instrukcji SQL jest o wiele trudniejsze niż to konieczne

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Ślepo ufający wkład użytkownika
2. Nieużywane sparametryzowane zapytania
3. Hasła tekstu jawnego

Moje błędy to 450 kolumn z tabelami dostępu, które zostały zebrane przez 8-letniego syna najlepszego przyjaciela dyrektora zarządzającego, pielęgnatora psów i podejrzana tabela przeglądowa, która istnieje tylko dlatego, że ktoś nie wie, jak poprawnie znormalizować strukturę danych.

Zazwyczaj ta tabela odnośników wygląda następująco:

ID INT,
Nazwa NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Data 1 DATETIME,
Data 2 DATETIME

Straciłem rachubę liczby klientów, którzy widziałem, którzy mają systemy oparte na takich ohydach.

Te, których najbardziej nie lubię, to

1. Używanie spacji podczas tworzenia tabel, sproków itp. Nie mam nic przeciwko CamelCase lub under_scores i liczby pojedynczej lub mnogiej i DUŻYM lub małym literom, ale muszę odwoływać się do tabeli lub kolumny [ze spacjami], zwłaszcza jeśli [jest dziwnie rozmieszczony] (tak, Wpadłem na to) naprawdę mnie denerwuje.

2. Dane zdormalizowane. Tabela nie musi być doskonale znormalizowana, ale kiedy napotkam tabelę pracowników, która ma informacje o ich bieżącym wyniku oceny lub ich podstawowej naturze, mówi mi, że prawdopodobnie będę musiał kiedyś stworzyć osobną tabelę i następnie spróbuj je zsynchronizować. Najpierw znormalizuję dane, a następnie, jeśli zobaczę miejsce, w którym pomaga denormalizacja, rozważę to.

3. Nadużywanie widoków lub kursorów. Widoki mają swój cel, ale kiedy każdy stół jest zawinięty w widok, jest to zbyt wiele. Musiałem użyć kursorów kilka razy, ale ogólnie możesz do tego użyć innych mechanizmów.

4. Dostęp. Czy program może być anty-wzorcem? W mojej pracy mamy SQL Server, ale wiele osób korzysta z dostępu ze względu na jego dostępność, „łatwość użycia” i „przyjazność” dla użytkowników nietechnicznych. Jest tu zbyt wiele, aby się w nie zaangażować, ale jeśli byłeś w podobnym środowisku, wiesz.

użyj SP jako prefiksu nazwy procedury składowania, ponieważ najpierw przeszuka ona lokalizację procedur systemowych, a nie niestandardowe.

Nadużywanie tymczasowych tabel i kursorów.

Do przechowywania wartości czasu należy używać tylko strefy czasowej UTC. Nie należy używać czasu lokalnego.

używając @@ IDENTITY zamiast SCOPE_IDENTITY ()

Cytat z tej odpowiedzi :

• @@ IDENTITY zwraca ostatnią wartość tożsamości wygenerowaną dla dowolnej tabeli w bieżącej sesji we wszystkich zakresach. Musisz tu być ostrożny, ponieważ jest to w wielu zakresach. Możesz uzyskać wartość z wyzwalacza, zamiast z bieżącego wyciągu.
• SCOPE_IDENTITY zwraca ostatnią wartość tożsamości wygenerowaną dla dowolnej tabeli w bieżącej sesji i bieżący zakres. Ogólnie to, czego chcesz użyć.
• IDENT_CURRENT zwraca ostatnią wartość tożsamości wygenerowaną dla określonej tabeli w dowolnej sesji i dowolnym zakresie. Pozwala to określić, z której tabeli chcesz uzyskać wartość, na wypadek gdyby dwie powyższe nie były dokładnie tym, czego potrzebujesz (bardzo rzadko). Możesz użyć tego, jeśli chcesz uzyskać bieżącą wartość TOŻSAMOŚCI dla tabeli, do której nie wstawiłeś rekordu.

Ponowne użycie „martwego” pola do czegoś, do czego nie było przeznaczone (np. Przechowywanie danych użytkownika w polu „Faks”) - bardzo kuszące jako szybkie rozwiązanie!

select some_column, ...
from some_table
group by some_column

i zakładając, że wynik zostanie posortowany według some_column. Widziałem to trochę w Sybase, gdzie założenie to obowiązuje (na razie).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Lub wkuwanie wszystkiego w jedną linię.

• FROM TableA, TableB WHERESkładnia ŁĄCZY zamiastFROM TableA INNER JOIN TableB ON

• Przyjmując założenie, że zapytanie zostanie zwrócone, posortowano w określony sposób bez wstawiania klauzuli ORDER BY, tylko dlatego, że tak to pokazało się podczas testowania w narzędziu zapytań.

Nauka języka SQL w ciągu pierwszych sześciu miesięcy ich kariery i nigdy nie uczenie się niczego przez następne 10 lat. W szczególności brak uczenia się lub efektywnego korzystania z funkcji okienkowania / analizy SQL. W szczególności użycie over () i podział według.

Funkcje okna, podobnie jak funkcje agregujące, wykonują agregację na zdefiniowanym zestawie (grupie) wierszy, ale zamiast zwracać jedną wartość na grupę, funkcje okna mogą zwracać wiele wartości dla każdej grupy.

Aby uzyskać ładny przegląd funkcji okienkowania, zobacz O'Reilly SQL Cookbook Dodatek A.

Muszę tu umieścić mojego obecnego faworyta, aby uzupełnić listę. Mój ulubiony antypattern nie testuje twoich zapytań .

Ma to zastosowanie, gdy:

1. Twoje zapytanie dotyczy więcej niż jednej tabeli.
2. Myślisz, że masz optymalny projekt zapytania, ale nie zawracaj sobie głowy testowaniem swoich założeń.
3. Akceptujesz pierwsze zapytanie, które działa, bez pojęcia, czy w ogóle jest ono zoptymalizowane.

Wszelkie testy przeprowadzane na nietypowych lub niewystarczających danych się nie liczą. Jeśli jest to procedura składowana, umieść instrukcję testu w komentarzu i zapisz ją wraz z wynikami. W przeciwnym razie umieść go w komentarzu w kodzie z wynikami.

Tymczasowe nadużycie tabeli.

W szczególności tego rodzaju rzeczy:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Nie buduj tabeli tymczasowej z zapytania, aby usunąć niepotrzebne wiersze.

I tak, widziałem strony kodu w tej formie w produkcyjnych bazach danych.

Pogląd przeciwny: nadmierna obsesja na punkcie normalizacji.

Większość systemów SQL / RBDB oferuje wiele funkcji (transakcji, replikacji), które są bardzo przydatne, nawet w przypadku nienormalizowanych danych. Miejsce na dysku jest tanie, a czasem może być prostsze (łatwiejszy kod, szybszy czas programowania) manipulowanie / filtrowanie / wyszukiwanie pobranych danych, niż pisanie schematu 1NF i radzenie sobie z wszystkimi zawartymi w nim problemami (złożone połączenia, nieprzyjemne podselekcje itp.).

Odkryłem, że nadmiernie znormalizowane systemy są często przedwczesną optymalizacją, szczególnie na wczesnych etapach rozwoju.

(więcej przemyśleń na ten temat ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Właśnie złożyłem to razem, w oparciu o niektóre odpowiedzi SQL tutaj na SO.

Poważnym przeciwnikiem jest myślenie, że wyzwalacze dotyczą baz danych, podobnie jak procedury obsługi zdarzeń do OOP. Istnieje przekonanie, że dowolną starą logikę można wprowadzić w wyzwalacze, które zostaną zwolnione, gdy transakcja (zdarzenie) nastąpi na stole.

Nie prawda. Jedną z dużych różnic jest to, że wyzwalacze są synchroniczne - z zemstą, ponieważ są one synchroniczne na określonej operacji, a nie na wierszu. Po stronie OOP dokładnie odwrotnie - zdarzenia to skuteczny sposób na implementację transakcji asynchronicznych.

Procedury przechowywane lub funkcje bez komentarzy ...

1) Nie wiem, czy to „oficjalny” anty-wzór, ale nie lubię i staram się unikać literałów łańcuchowych jako magicznych wartości w kolumnie bazy danych.

Przykład z „obrazu” tabeli MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Po prostu zauważam inną obudowę, kolejną rzeczą, której należy unikać)

Projektuję takie przypadki jak wyszukiwania int w tabelach ImageMediaType i ImageMajorMime z int kluczami podstawowymi.

2) konwersja daty / łańcucha, która zależy od określonych ustawień NLS

CONVERT(NVARCHAR, GETDATE())

bez identyfikatora formatu

Identyczne podzapytania w zapytaniu.

• Zmieniony widok - widok, który jest zmieniany zbyt często i bez uprzedzenia lub powodu. Zmiana zostanie zauważona w najbardziej nieodpowiednim czasie lub, co gorsza, będzie błędna i nigdy nie zauważona. Być może Twoja aplikacja ulegnie awarii, ponieważ ktoś wymyślił lepszą nazwę dla tej kolumny. Z reguły widoki powinny zwiększać użyteczność tabel podstawowych przy jednoczesnym utrzymaniu umowy z konsumentami. Napraw problemy, ale nie dodawaj funkcji ani gorzej zmieniaj zachowanie, aby utworzyć nowy widok. Aby ograniczyć ryzyko, nie udostępniaj widoków innym projektom i korzystaj z CTE, gdy pozwalają na to platformy. Jeśli twój sklep ma DBA, prawdopodobnie nie możesz zmienić poglądów, ale wszystkie twoje widoki będą nieaktualne i / lub bezużyteczne w takim przypadku.

• ! Paramed - czy zapytanie może mieć więcej niż jeden cel? Prawdopodobnie, ale następna osoba, która ją przeczyta, nie dowie się o niej aż do głębokiej medytacji. Nawet jeśli nie potrzebujesz ich teraz, są szanse, że tak będzie, nawet jeśli „tylko” to debugowanie. Dodanie parametrów skraca czas konserwacji i utrzymuje SUCHO. Jeśli masz klauzulę where, powinieneś mieć parametry.

• Sprawa bez CASE -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

Dwa, które najbardziej mi się podobają i mogą mieć znaczny koszt pod względem wydajności to:

• Używanie kursorów zamiast wyrażenia opartego na zestawie. Myślę, że ten występuje często, gdy programista myśli w sposób proceduralny.

• Używanie skorelowanych zapytań cząstkowych, gdy sprzężenie z tabelą pochodną może wykonać zadanie.

Umieszczanie rzeczy w tabelach tymczasowych, szczególnie osoby, które przechodzą z SQL Server na Oracle, mają zwyczaj nadużywania tabel tymczasowych. Wystarczy użyć zagnieżdżonych instrukcji select.

Programiści, którzy piszą zapytania, nie mając pojęcia, co powoduje, że aplikacje SQL (zarówno zapytania indywidualne, jak i systemy dla wielu użytkowników) są szybkie lub wolne. Obejmuje to ignorancję na temat:

• fizyczne strategie minimalizacji We / Wy, biorąc pod uwagę, że wąskim gardłem większości zapytań jest We / Wy, a nie CPU
• wpływ różnych rodzajów fizycznego dostępu do pamięci (np. wiele sekwencyjnych operacji we / wy będzie szybszych niż wiele małych losowych operacji we / wy, chociaż mniej, jeśli fizyczna pamięć jest dyskiem SSD!)
• jak ręcznie dostroić zapytanie, jeśli DBMS tworzy zły plan zapytań
• jak zdiagnozować niską wydajność bazy danych, jak „debugować” wolne zapytanie i jak odczytać plan zapytań (lub wyjaśnić, w zależności od wybranego DBMS)
• strategie blokowania w celu optymalizacji przepustowości i uniknięcia zakleszczeń w aplikacjach dla wielu użytkowników
• znaczenie grupowania i innych sztuczek w przetwarzaniu zestawów danych
• projektowanie tabel i indeksów w celu jak najlepszego zrównoważenia przestrzeni i wydajności (np. obejmowanie indeksów, utrzymywanie indeksów tam, gdzie to możliwe, zmniejszanie typów danych do niezbędnego minimalnego rozmiaru itp.)

Używanie SQL jako gloryfikowanego pakietu ISAM (Indexed Sequential Access Method). W szczególności zagnieżdżanie kursorów zamiast łączenia instrukcji SQL w jedną, choć większą, instrukcję. Jest to również liczone jako „nadużycie optymalizatora”, ponieważ tak naprawdę niewiele można zrobić. Można to połączyć z nieprzygotowanymi oświadczeniami dla maksymalnej nieefektywności:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

Prawidłowym rozwiązaniem (prawie zawsze) jest połączenie dwóch instrukcji SELECT w jedną:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Jedyną zaletą wersji z podwójną pętlą jest to, że można łatwo dostrzec przerwy między wartościami w tabeli 1, ponieważ pętla wewnętrzna się kończy. Może to być czynnikiem w raportach z łamaniem kontroli.

Ponadto sortowanie w aplikacji jest zwykle nie-nie.

Używanie kluczy podstawowych jako surogatu dla adresów rekordów i używanie kluczy obcych jako surogatu dla wskaźników osadzonych w rekordach.