Błędy w tworzeniu baz danych popełniane przez twórców aplikacji [zamknięty]

Kluczowe błędy w projektowaniu i programowaniu baz danych popełniane przez programistów

• Egoistyczne projektowanie i wykorzystanie baz danych. programiści często traktują bazę danych jako swój osobisty trwały magazyn obiektów bez uwzględniania potrzeb innych interesariuszy w danych. Dotyczy to również architektów aplikacji. Słaba konstrukcja bazy danych i integralność danych utrudnia osobom trzecim pracę z danymi i może znacznie zwiększyć koszty cyklu życia systemu. Raportowanie i MIS wydają się być słabym kuzynem w projektowaniu aplikacji i robione tylko jako przemyślenie.

• Nadużywanie danych denormalizowanych. nadmierne Przechowywanie denormalizowanych danych i próba utrzymania ich w aplikacji jest receptą na problemy z integralnością danych. Oszczędnie stosować denormalizację. Brak chęci dodania join do zapytania nie jest wymówką do denormalizacji.

• Boję się pisać SQL. SQL nie jest nauką rakietową i jest całkiem dobry w robieniu to praca. Warstwy mapowania O/R są całkiem dobre w wykonywaniu 95% zapytań, które są proste i dobrze pasują do tego modelu. Czasami SQL jest najlepszym sposobem na wykonanie zadania.

• Dogmatyczne zasady "nie przechowywanych procedur". niezależnie od tego, czy uważasz, że procedury przechowywane są złe, ten rodzaj dogmatycznej postawy nie ma miejsca w projekcie oprogramowania.

• Nie rozumiejąc projektowania baz danych. Normalizacja to twój przyjaciel i to Nie rakieta nauka. łączenie i cardinality są dość prostymi pojęciami - jeśli jesteś zaangażowany w tworzenie aplikacji bazodanowych, naprawdę nie ma usprawiedliwienia, aby ich nie rozumieć.

1. nie używanie kontroli wersji na schemacie bazy danych
2. Praca bezpośrednio z żywą bazą danych
3. nie czytanie i zrozumienie bardziej zaawansowanych koncepcji baz danych (indeksy, indeksy klastrowe, ograniczenia, zmaterializowane widoki, itp.)
4. Brak testu skalowalności ... dane testowe z tylko 3 lub 4 rzędów nigdy nie dadzą ci prawdziwego obrazu prawdziwego występu na żywo

Nadmierne użycie i / lub zależność od procedur składowanych.

Niektórzy programiści aplikacji postrzegają procedury składowane jako bezpośrednie rozszerzenie kodu warstwy środkowej / front-end. Wydaje się, że jest to częsta cecha wśród programistów stosów Microsoft (jestem jednym z nich, ale wyrosłem z niej) i produkuje wiele procedur składowanych, które wykonują złożoną logikę biznesową i przetwarzanie przepływu pracy. To jest o wiele lepiej zrobić gdzie indziej.

Procedury przechowywane są użyteczne tam, gdzie udowodniono, że niektóre prawdziwe czynnik techniczny wymusza ich wykorzystanie (na przykład wydajność i bezpieczeństwo), na przykład utrzymywanie agregacji / filtrowania dużych zbiorów danych "blisko danych".

Ostatnio musiałem pomóc w utrzymaniu i ulepszeniu dużej aplikacji desktopowej Delphi, z której 70% logiki biznesowej i reguł zostało zaimplementowanych w 1400 procedurach składowanych SQL Server (reszta w programach obsługi zdarzeń UI). To był koszmar, głównie ze względu na trudność wprowadzenia skutecznych testów jednostkowych do TSQL, brak enkapsulacji i ubogich narzędzi (debuggery, edytory).

Pracując w przeszłości z zespołem Java szybko przekonałem się, że często w tym środowisku panuje zupełne przeciwieństwo. Architekt Javy powiedział mi kiedyś: "baza danych służy do danych, a nie do kodu.".

W dzisiejszych czasach myślę, że błędem jest nieuwzględnianie w ogóle przechowywanych proc, ale powinny być używane oszczędnie (nie domyślnie) w sytuacjach, w których zapewniają użyteczne korzyści (patrz Pozostałe odpowiedzi).

Problem Numer jeden? Testują tylko w bazach zabawek. Więc nie mają pojęcia, że ich SQL będzie się czołgać, gdy baza danych się powiększy, a ktoś musi przyjść i naprawić to później(ten dźwięk, który słychać, to zgrzytanie zębami).

Nie używam indeksów.

Słaba wydajność spowodowana Skorelowanymi zapytaniami podrzędnymi

Przez większość czasu chcesz uniknąć skorelowanych zapytań podrzędnych. Zapytanie podrzędne jest skorelowane, jeśli wewnątrz zapytania podrzędnego znajduje się odniesienie do kolumny z zapytania zewnętrznego. Gdy tak się stanie, zapytanie podrzędne jest wykonywane co najmniej raz dla każdego zwracanego wiersza i może być wykonywane więcej razy, jeśli zostaną zastosowane inne warunki po zastosowaniu warunku zawierającego skorelowane zapytanie podrzędne.

Wybacz wymyślony przykład i składnia Oracle, ale powiedzmy, że chciałeś znaleźć wszystkich pracowników, którzy zostali zatrudnieni w każdym z Twoich sklepów od ostatniego czasu, gdy sklep zrobił mniej niż $10,000 sprzedaży w ciągu dnia.

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

Zapytanie podrzędne w tym przykładzie jest skorelowane z zewnętrznym zapytaniem przez store_id i będzie wykonywane dla każdego pracownika w systemie. Jednym ze sposobów optymalizacji tego zapytania jest przeniesienie zapytania podrzędnego do widoku wbudowanego.

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

W tym przykładzie zapytanie w klauzuli from jest teraz inline-view (znowu jakaś specyficzna składnia Oracle) i jest wykonywany tylko raz. W zależności od modelu danych, to zapytanie będzie prawdopodobnie wykonywane znacznie szybciej. Byłoby lepiej niż pierwsze zapytanie, ponieważ liczba pracowników wzrosła. Pierwsze zapytanie mogłoby działać lepiej, gdyby było niewielu pracowników i wiele sklepów (i być może wiele sklepów nie miało pracowników), a tabela daily_sales była indeksowana na store_id. Nie jest to prawdopodobny scenariusz, ale pokazuje, w jaki sposób skorelowane zapytanie może prawdopodobnie lepiej niż alternatywa.

Widziałem, jak młodsi Programiści korelują zapytania podrzędne wiele razy i zwykle miało to poważny wpływ na wydajność. Jednak podczas usuwania skorelowanych zapytań podrzędnych należy spojrzeć na explain plan przed i po, aby upewnić się, że nie pogarszasz wydajności.

Z mojego doświadczenia:
Nie komunikuje się z doświadczonymi osobami DBAs.

Używanie Access zamiast "prawdziwej" bazy danych. Istnieje wiele wielkich małych, a nawet darmowych baz danych, takich jak SQL Express, MySQL i SQLite, które będą działać i skalować znacznie lepiej. Aplikacje często muszą skalować się w nieoczekiwany sposób.

Zapominanie o ustawianiu relacji między tabelami. Pamiętam, że musiałem to posprzątać, kiedy po raz pierwszy zacząłem pracować u mojego obecnego pracodawcy.

Używanie Excela do przechowywania (ogromnych ilości) danych.

Widziałem firmy posiadające tysiące wierszy i używające wielu arkuszy roboczych (ze względu na limit wierszy 65535 w poprzednich wersjach programu Excel).

Excel dobrze nadaje się do raportów, prezentacji danych i innych zadań, ale nie powinien być traktowany jako baza danych.

Chciałbym dodać: Faworyzowanie "eleganckiego" kodu nad wysoce wydajnym kodem. Kod, który najlepiej działa na bazach danych, jest często brzydki dla oka twórcy aplikacji.

Wierząc, że bzdury o przedwczesnej optymalizacji. Bazy danych muszą uwzględniać wydajność w oryginalnym projekcie i w każdym późniejszym rozwoju. Wydajność to 50% projektu bazy danych (40% to integralność danych, a ostatnie 10% to bezpieczeństwo). Bazy danych, które nie są budowane od dołu do góry w celu wykonania będzie działać źle, gdy prawdziwi użytkownicy i prawdziwy ruch zostaną umieszczeni w bazie danych. Przedwczesna optymalizacja nie oznacza braku optymalizacji! Nie oznacza to, że powinieneś pisać kod, który prawie zawsze będzie działał źle, ponieważ znajdziesz go łatwiej (na przykład Kursory, które nigdy nie powinny być dozwolone w produkcyjnej bazie danych, chyba że wszystkie inne zawiodły). Oznacza to, że nie musisz patrzeć na wyciskanie tego ostatniego kawałka wydajności, dopóki nie będziesz musiał. Wiele wiadomo o tym, co sprawdzi się lepiej na bazy danych, ignorowanie tego w projektowaniu i rozwoju jest w najlepszym razie krótkowzroczne.

Nie używa parametryzowanych zapytań. Są bardzo przydatne w zatrzymywaniu SQL Injection.

Jest to szczególny przykład nie dezynfekcji danych wejściowych, wspomniany w innej odpowiedzi.

Nienawidzę, gdy programiści używają zagnieżdżonych instrukcji select lub nawet funkcji, które zwracają wynik instrukcji select wewnątrz części "SELECT" zapytania.

Przykład:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

W tym scenariuszu, jeśli MyTable zwraca 10000 wierszy, wynik jest tak, jakby zapytanie uruchomiło 20001 zapytań, ponieważ musiało uruchomić początkowe zapytanie plus zapytanie każda z pozostałych tabel raz dla każdej linii wyniku.

Programiści mogą się z tego wywinąć pracując w środowisku deweloperskim, gdzie zwracają tylko kilka wierszy danych, a tabele podrzędne zwykle mają tylko niewielką ilość danych, ale w środowisku produkcyjnym tego rodzaju zapytania mogą stać się wykładniczo kosztowne, ponieważ więcej danych jest dodawanych do tabel.

Lepszym (niekoniecznie idealnym) przykładem może być coś w stylu:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

Pozwala to na optymalizację bazy danych aby przetasować dane razem, zamiast requery na każdym rekordzie z tabeli głównej i zwykle znajduję, gdy muszę naprawić Kod, gdzie ten problem został utworzony, zwykle kończy się zwiększenie prędkości zapytań o 100% lub więcej, jednocześnie zmniejszając zużycie procesora i pamięci.

Dla baz danych opartych na SQL:

1. Brak korzystania z klastrowych indeksów lub wybór niewłaściwych kolumn do klastra.
2. nieużywanie typu danych szeregowych (autonumber) jako klucza podstawowego do połączenia z kluczem obcym (INT) w relacji tabeli rodzic/potomek.
3. nie aktualizowanie statystyk w tabeli, gdy wiele rekordów zostało wstawionych lub usuniętych.
4. nie reorganizowanie (tj. rozładowywanie, upuszczanie, ponowne tworzenie, ładowanie i ponowne indeksowanie) tabel po wstawieniu wielu wierszy lub usunięte (niektóre silniki fizycznie przechowują usunięte wiersze w tabeli z flagą delete.)
5. nie Korzystanie z FRAGMENT w wyrażeniu (jeśli jest obsługiwane) na dużych tabelach, które mają wysokie stawki transakcji.
6. wybór niewłaściwego typu danych dla kolumny!
7. nie wybiera odpowiedniej nazwy kolumny.
8. nie dodawanie nowych kolumn na końcu tabeli.
9. Nie tworzenie odpowiednich indeksów do obsługi często używanych zapytań.
10. tworzenie indeksów na kolumnach z kilkoma możliwymi wartości i tworzenie niepotrzebnych indeksów.
    ...więcej do dodania.

• Nie robienie kopii zapasowej przed naprawieniem jakiegoś problemu w bazie danych produkcji.

• Używanie poleceń DDL na przechowywanych obiektach (takich jak tabele, widoki) w procedurach przechowywanych.

• Strach przed używaniem przechowywanego proc lub strach przed używaniem zapytań ORM wszędzie tam, gdzie ten jest bardziej wydajny/odpowiedni do użycia.

• Ignorując korzystanie z profilera bazy danych, który może powiedzieć dokładnie, na co zapytanie ORM jest konwertowane w końcu, a tym samym zweryfikować logikę lub nawet dla debugowanie, gdy nie używasz ORM.

Nie wykonuje prawidłowego poziomu normalizacji . Chcesz się upewnić,że dane nie są zduplikowane i że w razie potrzeby dzielisz dane na różne. Musisz również upewnić się, że nie przestrzegasz normalizacji zbyt o ile to zaszkodzi wydajności.

Traktowanie bazy danych jako tylko mechanizmu przechowywania (tj. biblioteki zbiorów), a co za tym idzie podporządkowanie jej aplikacji (ignorowanie innych aplikacji współdzielących DANE)

• odrzucenie ORM jak Hibernate, z powodów takich jak "It' s too magical" lub "not on my database".
• poleganie zbyt mocno na ORM jak Hibernate i próba obkucia go tam, gdzie nie jest to właściwe.

1 - niepotrzebnie używanie funkcji na wartości w klauzuli where z wynikiem nieużywania tego indeksu.

Przykład:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

Zamiast

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

I w mniejszym stopniu: nie dodawanie indeksów funkcyjnych do tych wartości, które ich potrzebują...

2 - nie dodawanie ograniczeń kontroli w celu zapewnienia ważności danych. Ograniczenia mogą być używane przez optymalizator zapytań i naprawdę pomagają zapewnić, że możesz ufać swoim niezmiennikom. Jest nie ma powodu, żeby ich nie używać.

3 - Dodawanie nieznormalizowanych kolumn do tabel z czystego lenistwa lub presji czasu. Rzeczy zazwyczaj nie są zaprojektowane w ten sposób, ale ewoluują w ten sposób. Rezultatem jest mnóstwo pracy, która stara się posprzątać bałagan, gdy zostaniesz ugryziony przez utraconą integralność danych w przyszłych ewolucjach.

Pomyśl o tym, tabela bez danych jest bardzo tania do przeprojektowania. Stół z kilkoma milionami rekordów bez uczciwości... nie tak tanio do przeprojektować. Tak więc wykonanie poprawnego projektu podczas tworzenia kolumny lub tabeli jest amortyzowane w pikach.

4 - nie tyle o bazie danych per se, ale rzeczywiście irytujące. Nie dbając o jakość kodu SQL. Fakt, że Twój SQL jest wyrażony w tekście nie sprawia, że w porządku jest ukrywanie logiki w stertach algorytmów manipulacji ciągiem. Jest to całkowicie możliwe, aby napisać SQL w tekście w sposób, który jest rzeczywiście czytelny przez kolegę programisty.

To już zostało powiedziane, ale: indeksy, indeksy, indeksy . Widziałem tak wiele przypadków źle działających aplikacji internetowych dla przedsiębiorstw, które zostały naprawione przez zwykłe profilowanie (aby zobaczyć, które tabele były często trafiane), a następnie dodanie indeksu na tych tabelach. To nie wymaga nawet wiele w sposobie pisania SQL wiedzy, a wypłata jest ogromna.

Unikaj powielania danych jak plaga. Niektórzy opowiadają się za tym, że małe powielanie nie zaszkodzi i będzie popraw wydajność. Hej, nie mówię, że musisz torturować swój schemat do trzeciej normalnej formy, dopóki nie będzie tak abstrakcyjny, że nawet DBA nie wie, co się dzieje. Po prostu zrozum, że za każdym razem, gdy zduplikujesz zestaw nazw, kodów pocztowych lub kodów wysyłkowych, kopie wypadną ze sobą w końcu. To się stanie. A potem będziesz się kopać, uruchamiając cotygodniowy skrypt konserwacji.

I na koniec: użyj jasnego, spójnego, intuicyjnego nazewnictwa zjazd. W ten sam sposób, w jaki dobrze napisany fragment kodu powinien być czytelny, dobry schemat SQL lub zapytanie powinno być czytelne i praktycznie powiedzieć co robi, nawet bez komentarzy. Podziękujesz sobie za pół roku, kiedy będziesz musiał utrzymać się na stołach. "SELECT account_number, billing_date FROM national_accounts" jest nieskończenie łatwiejsze w obsłudze niż "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".

Nie wykonywanie odpowiedniego zapytania SELECT przed uruchomieniem zapytania DELETE (szczególnie w bazach produkcyjnych)!

Najczęstszy błąd, jaki widziałem od dwudziestu lat: nie planowanie z wyprzedzeniem. Wielu programistów tworzy bazę danych i tabele, a następnie stale modyfikuje i rozszerza tabele podczas tworzenia aplikacji. Efekt końcowy jest często bałagan i nieefektywne i trudne do czyszczenia lub uprościć później.

A) twarde wartości zapytania w łańcuchu
b) umieszczenie kodu zapytania bazy danych w akcji "OnButtonPress" w aplikacji Windows Forms

Widziałem oba.

Nie zwracanie wystarczającej uwagi na zarządzanie połączeniami baz danych w aplikacji. Następnie dowiadujesz się, że aplikacja, komputer, serwer i sieć są zatkane.

1. Myśląc, że są DBAs i data modelers / designers, gdy nie mają formalnej indoktrynacji jakiegokolwiek rodzaju w tych obszarach.

2. Myślenie, że ich projekt nie wymaga DBA, ponieważ to wszystko jest łatwe/trywialne.

3. Brak prawidłowego rozróżnienia między pracą, która powinna być wykonana w bazie danych, a pracą, która powinna być wykonana w aplikacji.

4. Nie sprawdzanie kopii zapasowych lub nie tworzenie kopii zapasowych.

5. Osadzanie surowego SQL w ich kod.

Oto link do filmu "Klasyczne błędy tworzenia baz danych i pięć sposobów ich przezwyciężenia " Scotta Walza

Brak zrozumienia modelu współbieżności baz danych i tego, jak wpływa to na rozwój. Łatwo jest dodawać indeksy i poprawiać zapytania po fakcie. Jednak aplikacje zaprojektowane bez należytego uwzględnienia hotspotów, zasobów i poprawne działanie (zakładając, że to co właśnie przeczytałeś jest nadal aktualne!) może wymagać znaczących zmian w warstwie bazy danych i aplikacji, aby później je skorygować.

Nie rozumiejąc, jak DBMS działa pod maską.

Nie można prawidłowo prowadzić drążka bez zrozumienia, jak działa sprzęgło. I nie możesz zrozumieć, jak korzystać z bazy danych bez zrozumienia, że tak naprawdę piszesz do pliku na dysku twardym.

Konkretnie:

1. Wiesz, co to jest indeks klastrowy? Pomyślałeś o tym, kiedy projektowałeś swój schemat?

2. Czy wiesz jak prawidłowo używać indeksów? Jak aby ponownie wykorzystać indeks? Wiesz, co to jest indeks przykrywający?

3. Świetnie, masz indeksy. Jak duży jest 1 wiersz w indeksie? Jak duży będzie indeks, gdy masz dużo danych? Czy to łatwo wpasuje się w pamięć? Jeśli nie będzie to bezużyteczne jako indeks.

4. Używałeś kiedyś EXPLAIN w MySQL? Świetnie. Teraz bądź szczery ze sobą: czy zrozumiałeś chociaż połowę tego, co widziałeś? Napraw to.

5. Rozumiesz Bufor zapytań? Czy wiesz, co sprawia, że zapytanie jest nieosiągalne?

6. Używasz MyISAM? Jeśli potrzebujesz pełnotekstowego wyszukiwania, MyISAM i tak jest do dupy. Użyj Sphinx. Następnie przełącz na Inno.

1. Używanie ORM do masowych aktualizacji
2. Wybór większej ilości danych niż potrzeba. Ponownie, zwykle robi się to przy użyciu ORM
3. odpalanie SQL w pętli.
4. brak dobrych danych testowych i zauważenie pogorszenia wydajności tylko na danych na żywo.