Co każdy programista powinien wiedzieć o bazach danych? [Zamknięte]

206

Niezależnie od tego, czy nam się to podoba, czy nie, wielu, jeśli nie większość z nas, programistów, albo regularnie pracuje z bazami danych, albo może kiedyś będzie musiała pracować z jednym z nich. Biorąc pod uwagę ilość niewłaściwego wykorzystywania i nadużyć na wolności oraz liczbę pytań związanych z bazami danych, które pojawiają się każdego dnia, można śmiało powiedzieć, że istnieją pewne koncepcje, które programiści powinni znać - nawet jeśli nie projektują ani nie pracują z nimi bazy danych dzisiaj. Więc:



Jakie są ważne pojęcia, które programiści i inni specjaliści ds. Oprogramowania powinni wiedzieć o bazach danych?


Wytyczne dotyczące odpowiedzi:


Skróć listę.
Jedna koncepcja na odpowiedź jest najlepsza.

Bądź konkretny .
„Modelowanie danych” może być ważną umiejętnością , ale co to dokładnie znaczy?

Wyjaśnij swoje uzasadnienie.
Dlaczego twoja koncepcja jest ważna? Nie mów tylko „użyj indeksów”. Nie popadaj w „najlepsze praktyki”. Przekonaj swoich odbiorców, aby dowiedzieć się więcej.

Pozytywne odpowiedzi, z którymi się zgadzasz.
Najpierw przeczytaj odpowiedzi innych osób. Jedna wysoko postawiona odpowiedź jest bardziej skutecznym stwierdzeniem niż dwie niskie. Jeśli masz więcej do dodania, dodaj komentarz lub odwołaj się do oryginału.

Nie głosuj za czymś tylko dlatego, że nie dotyczy to ciebie osobiście.
Wszyscy pracujemy w różnych domenach. Celem jest tutaj wskazanie początkującym bazom danych kierunku uzyskania dobrze ugruntowanego, wszechstronnego zrozumienia projektu bazy danych i rozwoju opartego na bazie danych, a nie konkurowania o tytuł najważniejszego.

Aaronaught
źródło
15
Po co głosować, aby to zamknąć? Jest to Wikia społeczności i dlatego jest odpowiednia.
David
5
Głosuję za ponownym otwarciem, jeśli zostanie zamknięty ... Chciałbym również zobaczyć listę rzeczy, które DBA powinny (ale nie wiedzą) o OOP i projektowaniu aplikacji / oprogramowania systemowego.
Charles Bretana
7
@gnovice: Słowo „subiektywne” w tym kontekście odnosi się do pytań, które są całkowicie kwestią opinii. „Co sądzisz o książce Joe Celko?” - to subiektywne pytanie. To pytanie wymaga obiektywnych informacji, tak się składa, że ​​nie ma jednej „właściwej” odpowiedzi. Myślę, że ważne jest, aby cofnąć się o krok i zapytać: „czy to tylko bezczynne przekomarzanie się, czy może jest przydatne dla niektórych programistów?” W każdym razie moje dwa centy - to nie tak, że zarabiam za to punkty rep. :-)
Aaronaught
6
Osobiście nienawidzę tych pytań. Prawie zawsze stanowią stosy osobistych opinii, lekkich na użyteczne informacje i ciężkich subiektywnych deklaracji. Ale nie chcę go zamykać tylko z tego powodu; to mogło być w połowie drogi przyzwoity, Aaron, jeśli ustawisz pewne wytyczne dla odpowiedzi: ODPOWIEDZI jednego tematu (co należy wiedzieć i dlaczego warto go znać), brak duplikatów, UP-głos co zgadzają się z ... i najbardziej co ważne, przenieś własne opinie do odpowiedzi, które to pokazują. W obecnej formie brzmi to jak post na blogu lub dyskusja na forum, z których żadne nie ma żadnego interesu w SO.
Shog9,
4
Uważam to za dość interesujące: „Jest to Wiki społeczności i dlatego jest odpowiednie”. Jak, u licha, CW może uczynić to odpowiednim? Albo pytanie jest właściwe czy nie, i myślę, że to pytanie jest droga do subiektywnych być pomocne, jeśli ktoś szuka odpowiedzi. To może być interesujące, ale to nie jedyna cecha, jaką musi mieć pytanie.
Georg Schölly,

Odpowiedzi:

106

Pierwszą rzeczą, którą programiści powinni wiedzieć o bazach danych, jest to: po co są bazy danych ? Nie to, jak działają, ani jak je budujesz, ani nawet jak piszesz kod, aby odzyskać lub zaktualizować dane w bazie danych. Ale po co one są?

Niestety odpowiedź na to pytanie jest ruchomym celem. W czasach największej liczby baz danych, od lat 70. do wczesnych lat 90., bazy danych służyły do ​​udostępniania danych. Jeśli korzystałeś z bazy danych i nie dzieliłeś się danymi, byłeś zaangażowany w projekt akademicki lub marnowałeś zasoby, w tym siebie. Utworzenie bazy danych i oswajanie DBMS były tak monumentalnymi zadaniami, że zwrot pod względem danych wykorzystywanych wielokrotnie musiał być ogromny, aby sprostać inwestycji.

W ciągu ostatnich 15 lat bazy danych zaczęły być używane do przechowywania trwałych danych związanych z tylko jedną aplikacją. Budowanie bazy danych dla MySQL , Access lub SQL Server stało się tak rutynowe, że bazy danych stały się niemal rutynową częścią zwykłej aplikacji. Czasami ta początkowa ograniczona misja jest podnoszona w górę przez pełzanie misji, gdy rzeczywista wartość danych staje się oczywista. Niestety bazy danych, które zostały zaprojektowane z myślą o jednym celu, często zawodzą, gdy zaczynają być przenoszone do roli obejmującej całe przedsiębiorstwo i mającej kluczowe znaczenie.

Drugą rzeczą, której programiści muszą się dowiedzieć o bazach danych, jest cały świat skoncentrowany na danych . Widok świata skoncentrowany na danych bardziej różni się od widoku świata skoncentrowanego na procesach, niż cokolwiek, czego większość programistów kiedykolwiek się nauczyła. W porównaniu z tą luką różnica między programowaniem strukturalnym a programowaniem obiektowym jest stosunkowo niewielka.

Trzecią rzeczą, której programiści muszą się nauczyć, przynajmniej w zarysie, jest modelowanie danych, w tym modelowanie danych koncepcyjnych, modelowanie danych logicznych i modelowanie danych fizycznych.

Koncepcyjne modelowanie danych to tak naprawdę analiza wymagań z punktu widzenia danych.

Logiczne modelowanie danych to zasadniczo zastosowanie określonego modelu danych do wymagań odkrytych w koncepcyjnym modelowaniu danych. Model relacyjny jest używany znacznie częściej niż jakikolwiek inny konkretny model, a programiści muszą się z pewnością nauczyć modelu relacyjnego. Zaprojektowanie silnego i odpowiedniego modelu relacyjnego dla pozrywalnych wymagań nie jest trywialnym zadaniem. Nie możesz zbudować dobrych tabel SQL, jeśli źle zrozumiesz model relacyjny.

Modelowanie danych fizycznych jest generalnie specyficzne dla DBMS i nie trzeba się go uczyć bardziej szczegółowo, chyba że deweloper jest również budowniczym baz danych lub DBA. Programiści muszą zrozumieć, w jakim stopniu fizyczny projekt bazy danych można oddzielić od logicznego projektu bazy danych, oraz zakres, w jakim tworzenie szybkiej bazy danych można osiągnąć jedynie poprzez ulepszenie projektu fizycznego.

Następną rzeczą, którą programiści muszą się nauczyć, jest to chociaż szybkość (wydajność) jest ważna, inne miary dobroci projektowej są jeszcze ważniejsze , takie jak możliwość zmiany i rozszerzenia zakresu bazy danych w dół drogi lub prostota programowania.

Wreszcie, każdy, kto ma problemy z bazami danych, musi to zrozumieć wartość danych często przewyższa system, który je przechwycił .

Uff!

Walter Mitty
źródło
Bardzo dobrze napisane! Perspektywa historyczna jest świetna dla osób, które nie pracowały w tym czasie w bazie danych (tj. Dla mnie).
Aaronaught,
6
Ładnie napisane. I myślę, że twoja ostatnia uwaga jest zbyt często ignorowana przez ludzi próbujących „po prostu załatwić sprawę”.
DaveE
1
Istnieje związek między tym, co napisałem, a tematami takimi jak wyjaśnienie planu, indeksowanie i normalizacja danych. Chciałbym omówić to połączenie bardziej szczegółowo na jakimś forum dyskusyjnym. SO nie jest takim forum.
Walter Mitty
1
Jeśli znalazłeś czytanie tego potwora, wyobraź sobie, jak to było pisać! Nie zamierzałem pisać eseju. Kiedy zacząłem, wydawało się, że po prostu płynie. Ktokolwiek dodał pogrubienie, naprawdę pomógł czytelnikom, IMO.
Walter Mitty
3
@ Walter Podałeś wyjaśnienia wszystkich swoich punktów oprócz tego: „Drugą rzeczą, którą programiści muszą się dowiedzieć o bazach danych, jest cały widok świata zorientowany na dane. Widok świata zorientowany na dane bardziej różni się od widoku zorientowanego na proces niż wszystko, czego większość programistów kiedykolwiek się nauczyła. W porównaniu z tą luką, różnica między programowaniem strukturalnym a programowaniem obiektowym jest stosunkowo niewielka ”. Czy mógłbyś to rozwinąć? Stwierdziłeś, że różnica jest duża, ale myślę, że naprawdę chciałbym zrozumieć widok zorientowany na dane i sposób, w jaki jest on oddzielony od widoku procesu.
jedd.ahyoung
73

Dobre pytanie. Oto niektóre przemyślenia w określonej kolejności:

  1. Normalizacja, przynajmniej do drugiej postaci normalnej, jest niezbędna.

  2. Niezbędna jest również integralność referencyjna, z odpowiednimi uwagami dotyczącymi usuwania i aktualizacji kaskadowej.

  3. Dobre i prawidłowe stosowanie ograniczeń kontrolnych. Pozwól bazie danych wykonać jak najwięcej pracy.

  4. Nie rozpraszaj logiki biznesowej zarówno w bazie danych, jak i w kodzie warstwy pośredniej. Wybierz jeden lub drugi, najlepiej w kodzie warstwy środkowej.

  5. Wybierz spójne podejście do kluczy podstawowych i kluczy klastrowych.

  6. Nie przekreślaj indeksu. Wybierz mądrze swoje indeksy.

  7. Spójne nazewnictwo tabel i kolumn. Wybierz standard i trzymaj się go.

  8. Ogranicz liczbę kolumn w bazie danych, które przyjmą wartości puste.

  9. Nie daj się ponieść wyzwalaczom. Mają swoje zastosowanie, ale mogą szybko się komplikować.

  10. Uważaj na UDF. Są świetne, ale mogą powodować problemy z wydajnością, gdy nie wiesz, jak często mogą być wywoływane w zapytaniu.

  11. Zdobądź książkę Celko na temat projektowania baz danych. Mężczyzna jest arogancki, ale zna się na rzeczy.

Randy Minder
źródło
1
staram się rozwinąć w punkcie 4. To temat, który zawsze mnie intrygował.
Brad
9
@David: Zawsze wolałem umieścić go w obu miejscach. W ten sposób jesteś chroniony przed błędami i błędami użytkownika. Nie ma powodu, aby każdą kolumnę można było zerować, ani zezwalać na wstawianie do niej wartości spoza zakresu 1-12 Month. Złożone reguły biznesowe to oczywiście inna historia.
Aaronaught
1
@Brad - Większość naszych aplikacji w pracy została wykonana na długo przed wdrożeniem solidnych procesów programowania. Dlatego logika biznesowa jest rozproszona wszędzie. Niektóre z nich znajdują się w interfejsie użytkownika, niektóre w środkowej warstwie, a niektóre w bazie danych. To bałagan. IMO, logika biznesowa należy do środkowej warstwy.
Randy Minder,
2
@David - Jeśli masz absolutną pewność, że modyfikacje bazy danych będą miały miejsce tylko w aplikacjach, być może masz rację. Jest to jednak prawdopodobnie dość rzadkie. Ponieważ użytkownicy prawdopodobnie wprowadzą dane bezpośrednio do bazy danych, dobrą praktyką jest również umieszczanie sprawdzania poprawności w bazie danych. Poza tym niektóre typy sprawdzania poprawności są po prostu wydajniej wykonywane w bazie danych.
Randy Minder,
1
Punkt 8 jest rzeczywiście ważny. Bardzo ważne jest, aby właściwie ustalić typy kolumn.
Chris Vest
22

Po pierwsze, programiści muszą zrozumieć, że istnieje coś, co należy wiedzieć o bazach danych. Nie są to tylko magiczne urządzenia, w których umieszczasz SQL i wyciągasz zestawy wyników, ale raczej bardzo skomplikowane programy z ich własną logiką i dziwactwami.

Po drugie, że istnieją różne konfiguracje baz danych do różnych celów. Nie chcesz, aby programista tworzył historyczne raporty z internetowej bazy danych transakcji, jeśli dostępna jest hurtownia danych.

Po trzecie, programiści muszą zrozumieć podstawowy SQL, w tym sprzężenia.

W przeszłości zależy to od stopnia zaangażowania deweloperów. Pracowałem na stanowiskach, w których byłem programistą i de facto DBA, gdzie DBA znajdowały się tuż przy przejściu, a DBA znajdowały się na ich własnym obszarze. (Nie lubię trzeciego.) Zakładając, że programiści są zaangażowani w projektowanie baz danych:

Muszą zrozumieć podstawową normalizację, przynajmniej pierwsze trzy normalne formy. Cokolwiek poza tym, zdobądź DBA. Dla osób z jakimkolwiek doświadczeniem w amerykańskich salach sądowych (i tutaj liczą się przypadkowe programy telewizyjne), istnieje mnemoniczny „Zależy od klucza, całego klucza i tylko klucza, więc pomóż Coddowi”.

Muszą mieć wskazówkę dotyczącą indeksów, co oznacza, że ​​powinni mieć pojęcie, jakich indeksów potrzebują i jak mogą wpłynąć na wydajność. Oznacza to brak posiadania bezużytecznych wskaźników, ale nie obawianie się ich dodawania w celu obsługi zapytań. Wszystko inne (np. Saldo) należy pozostawić DBA.

Muszą zrozumieć potrzebę integralności danych i być w stanie wskazać, gdzie weryfikują dane i co robią, jeśli napotkają problemy. Nie musi to znajdować się w bazie danych (gdzie trudno będzie wydać znaczący komunikat o błędzie dla użytkownika), ale musi być gdzieś.

Powinni mieć podstawową wiedzę o tym, jak uzyskać plan i jak go ogólnie przeczytać (przynajmniej tyle, aby stwierdzić, czy algorytmy są skuteczne, czy nie).

Powinni wiedzieć niejasno, co to jest wyzwalacz, jaki jest widok i że można podzielić partycje baz danych. Nie potrzebują żadnych szczegółów, ale muszą wiedzieć, aby zapytać DBA o te rzeczy.

Powinni oczywiście wiedzieć, aby nie mieszać się z danymi produkcyjnymi, kodem produkcyjnym lub czymkolwiek podobnym, i powinni wiedzieć, że cały kod źródłowy trafia do VCS.

Bez wątpienia o czymś zapomniałem, ale przeciętny programista nie musi być DBA, pod warunkiem, że jest pod ręką prawdziwy DBA.

David Thornley
źródło
19

Podstawowe indeksowanie

Zawsze jestem zszokowany widząc tabelę lub całą bazę danych bez indeksów lub indeksy arbitralne / bezużyteczne. Nawet jeśli nie projektujesz bazy danych i po prostu musisz napisać kilka zapytań, nadal musisz zrozumieć przynajmniej:

  • Co jest indeksowane w Twojej bazie danych, a co nie:
  • Różnica między typami skanów, ich wyborem i sposobem, w jaki piszesz zapytanie, może wpłynąć na ten wybór;
  • Pojęcie zasięgu (dlaczego nie należy po prostu pisać SELECT *);
  • Różnica między indeksem klastrowym a nieklastrowym;
  • Dlaczego więcej / większe indeksy niekoniecznie są lepsze;
  • Dlaczego powinieneś unikać zawijania kolumn filtrów w funkcjach.

Projektanci powinni również zdawać sobie sprawę z typowych anty-wzorów indeksu, na przykład:

  • Anty-wzorzec Access (indeksowanie każdej kolumny, jedna po drugiej)
  • Anti-pattern Catch-All (jeden ogromny indeks dla wszystkich lub większości kolumn, najwyraźniej stworzony pod błędnym wrażeniem, że przyspieszy każde możliwe zapytanie dotyczące dowolnej z tych kolumn).

Jakość indeksowania bazy danych - i to, czy wykorzystujesz to przy pisaniu zapytań - stanowi zdecydowanie najbardziej znaczącą część wydajności. 9 z 10 pytań zadawanych na SO i innych forach narzekających na niską wydajność niezmiennie okazuje się być wynikiem złego indeksowania lub niewymowalnego wyrażenia.

Aaronaught
źródło
Czy możesz opracować „zasięg”? Rozumiem, dlaczego SELECT * nie jest dobrym nawykiem, ale nie znam znaczenia „zasięgu” i zastanawiam się, czy odnosi się to do innego powodu, aby uniknąć SELECT *.
Edmund,
1
@Edmund: Indeks obejmuje zapytanie, jeśli wszystkie pola wyjściowe są częścią indeksu (jako kolumny indeksowane lub INCLUDEkolumny w SQL Server). Jeśli jedynym dostępnym indeksem dla danego zapytania nie jest zasłaniający, należy pobrać wszystkie wiersze, jeden po drugim, co jest bardzo powolną operacją i przez większość czasu optymalizator zapytań zdecyduje, że nie jest warto i zamiast tego wykonaj pełne skanowanie indeksu / tabeli. Dlatego nie piszesz SELECT *- to praktycznie gwarantuje, że żaden indeks nie obejmie zapytania.
Aaronaught,
dzięki! Chociaż jako użytkownik PostgreSQL nie muszę się już martwić o takie rzeczy (jeszcze?): Indeksy nie zawierają informacji o widoczności, więc krotki tabel zawsze muszą być skanowane. Zasadniczo wygląda to jednak na dość ważny czynnik.
Edmund
@Edmund: PostgreSQL może nie mieć INCLUDEkolumn (nie mogę tego powiedzieć na pewno), ale to nie znaczy, że nie możesz umieścić kolumn, które chcesz pokryć w rzeczywistych danych indeksu. Właśnie to musieliśmy robić w SQL Server 2000 dni. Zasięg nadal ma znaczenie bez względu na to, na którym DBMS jesteś.
Aaronaught
16

Normalizacja

Zawsze przygnębia mnie myśl, że ktoś próbuje napisać zbyt skomplikowane zapytanie, które byłoby całkowicie proste dzięki znormalizowanemu projektowi („Pokaż mi całkowitą sprzedaż według regionu”).

Jeśli zrozumiesz to na wstępie i odpowiednio zaprojektujesz, zaoszczędzisz sobie dużo bólu później. Łatwo jest denormalizować wydajność po normalizacji; normalizacja bazy danych, która nie została zaprojektowana w ten sposób od samego początku, nie jest taka łatwa.

Przynajmniej powinieneś wiedzieć, co to jest 3NF i jak się tam dostać. W przypadku większości transakcyjnych baz danych jest to bardzo dobra równowaga między ułatwieniem pisania zapytań a utrzymaniem dobrej wydajności.

Aaronaught
źródło
14

Jak działają indeksy

To chyba nie jest najważniejszy, ale na pewno najbardziej niedoceniany temat.

Problem z indeksowaniem polega na tym, że samouczki SQL zwykle w ogóle o nich nie wspominają, a wszystkie przykłady zabawek działają bez żadnego indeksu.

Nawet bardziej doświadczeni programiści potrafią pisać całkiem dobre (i złożone) SQL bez wiedzy o indeksach niż „ Indeks sprawia, że ​​zapytanie jest szybkie ”.

To dlatego, że bazy danych SQL wykonują bardzo dobrą robotę, pracując jako czarna skrzynka:

Powiedz mi, czego potrzebujesz (daj mi SQL), zajmę się tym.

I to działa idealnie, aby uzyskać prawidłowe wyniki. Autor SQLa nie musi wiedzieć, co robi system za kulisami - dopóki wszystko nie stanie się zbyt wolne .....

Wtedy indeksowanie staje się tematem. Ale zwykle jest to bardzo późno i ktoś (jakaś firma?) Ma już poważny problem.

Dlatego uważam, że indeksowanie jest tematem numer jeden, którego nie można zapomnieć podczas pracy z bazami danych . Niestety bardzo łatwo o tym zapomnieć.

Zrzeczenie się

Argumenty zapożyczono ze wstępu do mojego darmowego eBooka „ Use The Index, Luke ”. Sporo czasu spędzam na wyjaśnianiu, jak działają indeksy i jak z nich właściwie korzystać.

Markus Winand
źródło
12

Chcę tylko zwrócić uwagę na to, że wydaje się, że większość odpowiedzi zakłada, że ​​baza danych jest wymienna z relacyjnymi bazami danych. Istnieją również bazy danych obiektów, bazy danych plików płaskich. Ważne jest, aby ocenić potrzeby danego projektu oprogramowania. Z perspektywy programisty decyzja dotycząca bazy danych może być opóźniona do później. Z drugiej strony modelowanie danych można osiągnąć wcześnie i doprowadzić do dużego sukcesu.

Myślę, że modelowanie danych jest kluczowym składnikiem i jest stosunkowo starą koncepcją, ale zostało zapomniane przez wielu w branży oprogramowania. Modelowanie danych, zwłaszcza modelowanie pojęciowe, może ujawnić funkcjonalne zachowanie systemu i może być traktowane jako mapa drogowa rozwoju.

Z drugiej strony wymagany typ bazy danych można określić na podstawie wielu różnych czynników, takich jak środowisko, liczba użytkowników i dostępny lokalny sprzęt, taki jak miejsce na dysku twardym.

FernandoZ
źródło
Czy masz na myśli tworzenie diagramów relacji między bytami?
crosenblum
Tak ... czy zapomniałem wspomnieć o ERD? :-)
FernandoZ
+1 ... Ale musisz zdać sobie sprawę, że jesteś na SO: dom hydraulików spędzających swoje dni na naprawianiu niedopasowania impedancji ORM, więc wszystko, co wiedzą, jedzą i myślą, to nie tylko relacyjny, ale „SQL” :)
SyntaxT3rr0r
11

Unikanie wstrzykiwania SQL i jak zabezpieczyć bazę danych

iChaib
źródło
9

Każdy programista powinien wiedzieć, że jest to nieprawda: „Profilowanie operacji na bazie danych różni się całkowicie od kodu profilowania”.

Istnieje wyraźny Big-O w tradycyjnym znaczeniu. Kiedy robisz EXPLAIN PLAN(lub równoważny), widzisz algorytm. Niektóre algorytmy wykorzystują zagnieżdżone pętle i są O ( n ^ 2). Inne algorytmy obejmują wyszukiwanie B-drzewa i są O ( n log n ).

To jest bardzo, bardzo poważne. Kluczowe znaczenie ma zrozumienie, dlaczego indeksy mają znaczenie. Jest to kluczowe dla zrozumienia kompromisów między szybkością a normalizacją i denormalizacją. Zasadnicze znaczenie ma zrozumienie, dlaczego hurtownia danych wykorzystuje schemat gwiazdy, który nie jest znormalizowany dla aktualizacji transakcyjnych.

Jeśli nie masz pewności co do używanego algorytmu, wykonaj następujące czynności. Zatrzymać. Wyjaśnij plan wykonania zapytania. Dostosuj odpowiednio indeksy.

Następstwem tego jest: Więcej indeksów nie jest lepszych.

Czasami indeks skoncentrowany na jednej operacji spowalnia inne operacje. W zależności od stosunku dwóch operacji dodanie indeksu może mieć dobre efekty, brak ogólnego wpływu lub może mieć negatywny wpływ na ogólną wydajność.

S.Lott
źródło
Miałem przeczucie, że zostanie źle przyjęte. Przez „tradycyjny” rozumiałem to, że tak naprawdę nie masz żadnej kontroli nad algorytmami, a jedynie zdolność wpływania na to, które z nich są używane. W każdym razie usunąłem ten język, ponieważ nie chcę niczego zbyt kontrowersyjnego w głównym poście.
Aaronaught
@Aaron: Ty nie masz kontroli nad algorytmami. Do tego służą indeksy.
S.Lott,
Hmm, więc możesz zmienić, jakiego rodzaju algorytmu sortowania używa DE? Jakie struktury danych są używane dla indeksu? Wolałbym nie kłócić się o ten punkt, dlatego go wyjąłem, ale podtrzymuję podstawową ideę, że masz dużo mniej kontroli podczas pracy z bazą danych w porównaniu do kodu.
Aaronaught
@Aaron: Mniej kontroli nie eliminuje obowiązku faktycznego zrozumienia, czy zapytanie to * O ** (* n ^ 2) lub * O ** (* n log n ) lub tylko ** O ** (n). Mniej kontroli nie znosi obowiązku faktycznego rozumienia, co się dzieje i dowiedzenia się, jak to kontrolować.
S.Lott,
@ S.Lott: Myślę, że jesteśmy po tej samej stronie tutaj, jak ja sugeruje większą profilowania obciążenia dla baz danych - „Ty potrzebujesz wiedzieć ... [jak] czytaj planu kwerend”. Ale moja edycja wydaje się być wycofana, więc ... Myślę, że należy ona teraz do społeczności.
Aaronaught,
8

Myślę, że każdy programista powinien zrozumieć, że bazy danych wymagają innego paradygmatu .

Podczas pisania zapytania w celu uzyskania danych potrzebne jest podejście oparte na zestawie. Wiele osób z interaktywnym doświadczeniem ma z tym problem. A jednak, kiedy to przyjmą, mogą osiągnąć znacznie lepsze wyniki, nawet jeśli rozwiązaniem może nie być to, które po raz pierwszy pojawiło się w ich umysłach skoncentrowanych na iteracji.

Rob Farley
źródło
Proszę wyjaśnić, co należy rozumieć przez podejście „oparte na zestawie”
Vivian River,
1
Że powinieneś patrzeć na dane jako na zbiory i uważać swoje problemy za potencjalnie rozwiązane przez arytmetykę zbiorów - obejmującą funkcje rankingowe tam, gdzie jest to wymagane, podzapytania, agregacje i tak dalej. Wielu programistów myśli o tym, co należy zrobić w każdym rzędzie, czyli myśleniu iteracyjnym.
Rob Farley,
8

Doskonałe pytanie. Zobaczmy, najpierw nikt nie powinien zastanawiać się nad zapytaniem do bazy danych, która nie do końca rozumie sprzężenia. To jak prowadzenie samochodu bez wiedzy, gdzie jest kierownica i hamulce. Musisz także znać typy danych i jak wybrać najlepszy.

Inną rzeczą, którą programiści powinni zrozumieć, są trzy rzeczy, o których należy pamiętać przy projektowaniu bazy danych:

  1. Integralność danych - jeśli na danych nie można polegać w zasadzie nie masz danych - oznacza to, że nie stosuj wymaganej logiki w aplikacji, ponieważ wiele innych źródeł może dotykać bazy danych. Ograniczenia, klucze obce, a czasem wyzwalacze są niezbędne do zapewnienia integralności danych. Nie zaniedbuj ich używania, ponieważ ich nie lubisz lub nie chcesz, aby ci przeszkadzało ich zrozumienie.

  2. Wydajność - bardzo trudno jest refaktoryzować słabo działającą bazę danych i wydajność należy brać pod uwagę od samego początku. Istnieje wiele sposobów wykonania tego samego zapytania, a niektóre z nich są prawie zawsze szybsze. Krótkowzroczność polega na tym, aby nie uczyć się i nie używać tych metod. Przeczytaj kilka książek na temat dostrajania wydajności przed projektowaniem zapytań lub struktur baz danych.

  3. Bezpieczeństwo - te dane są życiową krwią Twojej firmy, często zawierają również dane osobowe, które mogą zostać skradzione. Naucz się chronić swoje dane przed atakami typu SQL injection, oszustwami i kradzieżą tożsamości.

Podczas wyszukiwania w bazie danych łatwo jest uzyskać złą odpowiedź. Upewnij się, że dokładnie rozumiesz swój model danych. Pamiętaj, że często rzeczywiste decyzje są podejmowane na podstawie danych zwracanych przez zapytanie. Kiedy jest źle, podejmowane są złe decyzje biznesowe. Możesz zabić firmę z powodu złych zapytań lub stracić dużego klienta. Dane mają znaczenie, programiści często zapominają o tym.

Dane prawie nigdy nie znikają, pomyśl raczej o przechowywaniu danych w czasie, niż o tym, jak je dziś uzyskać. Ta baza danych, która działała dobrze, gdy miała sto tysięcy rekordów, może nie być tak ładna za dziesięć lat. Aplikacje rzadko trwają tak długo, jak dane. Jest to jeden z powodów, dla których projektowanie pod kątem wydajności ma kluczowe znaczenie.

Twoja baza danych prawdopodobnie będzie wymagać pól, których aplikacja nie musi widzieć. Rzeczy takie jak identyfikatory GUID do replikacji, pola wstawiania daty. itp. Może być również konieczne przechowywanie historii zmian i tego, kto je wprowadził, i być w stanie przywrócić złe zmiany z tego magazynu. Zastanów się, jak zamierzasz to zrobić, zanim przyjdziesz, zapytaj witrynę internetową, jak rozwiązać problem polegający na tym, że zapomniałeś wstawić klauzulę where do aktualizacji i zaktualizowałeś całą tabelę.

Nigdy nie rozwijaj w nowszej wersji bazy danych niż wersja produkcyjna. Nigdy, nigdy, nigdy nie rozwijaj bezpośrednio w oparciu o produkcyjną bazę danych.

Jeśli nie masz administratora bazy danych, upewnij się, że ktoś tworzy kopie zapasowe i wie, jak je przywrócić, i przetestował je.

Kod bazy danych jest kodem, nie ma usprawiedliwienia dla nie utrzymywania go w kontroli źródła, tak jak reszta kodu.

HLGEM
źródło
6

Ewolucyjny projekt bazy danych. http://martinfowler.com/articles/evodb.html

Te zwinne metodyki sprawiają, że proces zmiany bazy danych jest zarządzalny, przewidywalny i testowalny.

Deweloperzy powinni wiedzieć, co trzeba zrobić, aby refaktoryzować produkcyjną bazę danych w zakresie kontroli wersji, ciągłej integracji i automatycznych testów.

Proces projektowania ewolucyjnej bazy danych ma aspekty administracyjne, na przykład kolumna ma zostać usunięta po pewnym okresie użytkowania we wszystkich bazach danych tej bazy kodu.

Przynajmniej wiem, że istnieje koncepcja i metodologie refaktoryzacji baz danych. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Klasyfikacja i opis procesu umożliwiają wdrożenie oprzyrządowania również dla tych refaktoryzacji.

George Polevoy
źródło
Uwielbiam koncepcję refaktoryzacji, ale jeśli chodzi o DB, prawdziwym dużym problemem z nią są trwałe dane. refaktoryzacja bazy danych często wiąże się z migracją danych, która w rzeczywistości jest trudna, szczególnie jeśli nie pozwala się na żadne przestoje systemu. również wycofanie nie jest trywialne. Moim zdaniem trudności w prawidłowym / bezpiecznym wdrażaniu + strategiach wycofywania są często przeszkadzające w refaktoryzowaniu DB tak lekkim jak kod aplikacji. samo w sobie często ma sens refaktoryzacja rzeczy, ale zawsze trzeba przeważyć koszty / korzyści.
manuel aldana
Zobacz także „Refaktoryzacja baz danych Amblera” ( amazon.com/Refactoring-Databases-Evolutionary-Database-Design/… ).
Jonathan Leffler
5

Z mojego doświadczenia z relacyjnymi bazami danych każdy programista powinien wiedzieć:

- Różne typy danych :

Użycie odpowiedniego typu do prawidłowego zadania sprawi, że projekt DB będzie bardziej niezawodny, zapytania będą szybsze, a życie łatwiejsze.

- Dowiedz się więcej o 1xM i MxM :

To chleb powszedni do relacyjnych baz danych. Musisz zrozumieć relacje „jeden do wielu” i „wiele do wielu” i zastosować je, gdy jest to właściwe.

- Zasada „ KISS ” dotyczy również DB :

Prostota zawsze działa najlepiej. Pod warunkiem, że przestudiowałeś sposób działania DB, unikniesz niepotrzebnej złożoności, która doprowadzi do problemów związanych z konserwacją i prędkością.

- Wskaźniki :

Nie wystarczy, jeśli wiesz, czym one są. Musisz zrozumieć, kiedy ich używać, a kiedy nie.


również:

  • Algebra boolowska jest twoim przyjacielem
  • Obrazy: Nie przechowuj ich na DB. Nie pytaj dlaczego.
  • Przetestuj DELETE za pomocą SELECT
Anax
źródło
+1 za obrazy. Zastąpiłbym jednak „Obrazy” „BLOBAMI”.
Agnel Kurian,
Nie jestem do końca pewien co do „prostoty”. Najprostszą możliwą bazą danych jest jedna gigantyczna tabela z wieloma varchar(max)kolumnami. Relacyjne bazy danych powinny być znormalizowane , a nie uproszczone .
Aaronaught
Twoje obawy zostały omówione wcześniej w części „Typy danych” mojego postu. Miałem na myśli (niepotrzebne) stosowanie procedur przechowywanych / wyzwalaczy / kursorów i tak dalej.
Anax,
5

Chciałbym, aby wszyscy, zarówno DBA, jak i deweloperzy / projektanci / architekci, lepiej zrozumieli, jak prawidłowo modelować domenę biznesową oraz jak mapować / tłumaczyć ten model domeny biznesowej na znormalizowany model logiczny bazy danych, zoptymalizowany model fizyczny i odpowiedni obiektowy model klasy, z których każdy jest (może być) inny, z różnych powodów, i rozumie, kiedy, dlaczego i jak różnią się (lub powinny) być od siebie.

Charles Bretana
źródło
5

Powiedziałbym, że silne podstawowe umiejętności SQL. Do tej pory widziałem wielu programistów, którzy wiedzą trochę o bazach danych, ale zawsze proszą o wskazówki, jak sformułować dość proste zapytanie. Zapytania nie zawsze są tak łatwe i proste. Musisz używać wielu sprzężeń (wewnętrzny, lewy itp.) Podczas odpytywania dobrze znormalizowanej bazy danych.

MaxiWheat
źródło
5

O następującym komentarzu do odpowiedzi Waltera M.:

„Bardzo dobrze napisane! I historyczna perspektywa jest świetna dla osób, które nie pracowały w tym czasie w bazie danych (tj. Dla mnie)”.

Perspektywa historyczna jest w pewnym sensie absolutnie kluczowa. „Ci, którzy zapominają o historii, skazani są na jej powtórzenie”. Od fr. XML powtarzające się błędy hierarchiczne z przeszłości, graficzne bazy danych powtarzające błędy sieciowe z przeszłości, systemy OO narzucające użytkownikom model hierarchiczny, podczas gdy wszyscy, nawet z jedną dziesiątą mózgu, powinni wiedzieć, że model hierarchiczny nie jest odpowiedni dla ogólnych- reprezentacja celu rzeczywistego świata, etcetera, etcetera.

Jeśli chodzi o samo pytanie:

Każdy programista bazy danych powinien wiedzieć, że „Relacyjny” nie jest równy „SQL”. Wtedy zrozumieliby, dlaczego są tak beznadziejnie zawiedzeni przez dostawców DBMS i dlaczego powinni mówić tym samym dostawcom, aby wymyślili lepsze rzeczy (np. DBMS, które są naprawdę relacyjne), jeśli chcą dalej ssać zabawne ilości pieniądze od klientów za takie gówniane oprogramowanie).

I każdy programista bazy danych powinien wiedzieć wszystko o algebrze relacyjnej. Wtedy nie byłoby już ani jednego programisty, który musiałby publikować te głupie pytania „Nie wiem, jak wykonać swoją pracę i chcę, żeby ktoś inny to dla mnie zrobił” na Stack Overflow.

Erwin Smout
źródło
1
Zgadzam się, że programista musi wiedzieć, gdzie SQL i RDM się różnią. Powiedziawszy to, rozsądne użycie RDM może być nieocenioną pomocą dla projektanta bazy danych, nawet jeśli implementacją jest SQL.
Walter Mitty,
1
Na wypadek, gdybyś zapomniał, George Santayana, napisał ten klasyczny cytat ...
crosenblum
5

Myślę, że omówiono tutaj wiele szczegółów technicznych i nie chcę ich dodawać. Jedno, co chcę powiedzieć, jest bardziej towarzyskie niż techniczne, nie daj się zwieść pułapce „DBA wiedząc, co najlepsze” jako twórcy aplikacji.

Jeśli masz problemy z wydajnością zapytania, przejmij odpowiedzialność za problem. Przeprowadź własne badania i nalegaj na DBA, aby wyjaśnić, co się dzieje i jak ich rozwiązania rozwiązują problem.

Po zakończeniu badań wymyśl własne sugestie. Oznacza to, że staram się znaleźć wspólne rozwiązanie problemu, zamiast pozostawiać problemy z bazą danych DBA.

HeretoLearn
źródło
dobra odpowiedź. Każdy z nas ma swój własny obszar, który przyczyniamy się do każdego problemu lub rozwiązania.
crosenblum
5

Prosty szacunek.

  • To nie tylko repozytorium
  • Prawdopodobnie nie wiesz lepiej niż sprzedawca lub DBA
  • Nie będziesz go wspierać o 3 nad ranem, gdy wydzierają do ciebie wyżsi menedżerowie
GB
źródło
3

Rozważ Denormalizację jako możliwego anioła, a nie diabła, a także rozważ bazy danych NoSQL jako alternatywę dla relacyjnych baz danych.

Ponadto uważam, że model Entity-Relation jest obowiązkowy dla każdego programisty, nawet jeśli nie projektujesz baz danych. Pozwoli ci to dokładnie zrozumieć, o co chodzi w Twojej bazie danych.

iChaib
źródło
3

Nigdy nie wstawiaj danych z niewłaściwym kodowaniem tekstu.

Gdy baza danych zostanie zanieczyszczona wieloma kodowaniami, najlepsze, co możesz zrobić, to zastosować jakąś kombinację heurystyki i pracy fizycznej.

mikerobi
źródło
2
Co to jest „nieprawidłowe kodowanie tekstu” i jak to się dzieje?
Gennady Vanin Геннадий Ванин
1
@ vgv8, dzieje się tak, gdy klient pozwala użytkownikom na przesyłanie tekstu w dowolnym kodowaniu, które zapisujesz na ślepo. Następnie, gdy trzeba wykonać jakąś transformację lub analizę, kod się psuje, ponieważ aplikacja zakłada utf-8, ale niektórzy idioci dodali dane utf-16, a twój program popełnia błędy lub zaczyna bełkotać.
mikerobi
3

Oprócz stosowanych przez nie opcji składni i pojęć (takich jak sprzężenia, wyzwalacze i procedury składowane) jedna rzecz, która będzie krytyczna dla każdego programisty korzystającego z bazy danych, to:

Dowiedz się, w jaki sposób Twój silnik wykona określone zapytanie.

Powodem, dla którego uważam to za tak ważne, jest po prostu stabilność produkcji. Powinieneś wiedzieć, jak działa twój kod, abyś nie zatrzymywał całego wykonywania w swoim wątku podczas oczekiwania na zakończenie długiej funkcji, więc dlaczego nie chcesz wiedzieć, jak twoje zapytanie wpłynie na bazę danych, twój program, a może nawet serwer?

W rzeczywistości jest to coś, co uderzyło w mój zespół badawczo-rozwojowy więcej razy niż brakujące średniki lub tym podobne. Zakłada się, że zapytanie zostanie wykonane szybko, ponieważ dzieje się tak w ich systemie programistycznym z zaledwie kilkoma tysiącami wierszy w tabelach. Nawet jeśli produkcyjna baza danych jest tego samego rozmiaru, jest bardziej niż prawdopodobne, że będzie używana o wiele częściej, a zatem cierpi z powodu innych ograniczeń, takich jak wielu użytkowników uzyskujących dostęp do niej w tym samym czasie, lub coś nie tak z innym zapytaniem w innym miejscu, co opóźnia wynik tego zapytania.

Nawet proste rzeczy, takie jak sprzężenia wpływają na wydajność zapytania, są nieocenione w produkcji. Istnieje wiele funkcji wielu silników baz danych, które ułatwiają koncepcyjnie, ale mogą wprowadzić gotchas w działaniu, jeśli nie zostaną wyraźnie przemyślane.

Poznaj proces wykonywania silnika bazy danych i zaplanuj go.

TodPunk
źródło
3

Dla profesjonalnego dewelopera na środkowej drodze, który często korzysta z baz danych (pisanie / obsługa zapytań codziennie lub prawie codziennie), myślę, że oczekiwania powinny być takie same jak w każdej innej dziedzinie: Napisałeś jedną na studiach .

Każdy maniak C ++ napisał klasę smyczkową na studiach. Każdy maniak grafiki napisał raytracer na studiach. Każdy maniak internetowy pisał interaktywne strony internetowe (zwykle zanim mieliśmy „frameworki”) na studiach. Każdy nerd sprzętowy (a nawet nerd programowy) zbudował procesor na studiach. Każdy lekarz przeprowadził sekcję całego zwłok na studiach, nawet jeśli zamierza tylko zmierzyć moje ciśnienie krwi i powiedzieć, że mój poziom cholesterolu jest dziś zbyt wysoki. Dlaczego bazy danych miałyby być inne?

Niestety, z jakiegoś powodu wydają się dziś inne. Ludzie chcą, aby programiści .NET wiedzieli, jak działają łańcuchy w C , ale elementy wewnętrzne twojego RDBMS nie powinny zbytnio cię martwić .

Jest praktycznie niemożliwe, aby uzyskać ten sam poziom zrozumienia po prostu czytając o nich, a nawet schodząc z góry. Ale jeśli zaczniesz od dołu i zrozumiesz każdy element, wtedy stosunkowo łatwo będzie ustalić specyfikę swojej bazy danych. Nawet rzeczy, których wielu maniaków baz danych nie wydaje się narzekać, na przykład kiedy używać nierelacyjnej bazy danych.

Może to trochę surowe, zwłaszcza jeśli nie studiowałeś informatyki na studiach. Stonuję trochę: mógłbyś napisać jeden dzisiaj , całkowicie od zera. Nie dbam o to, czy znasz specyfikę działania optymalizatora zapytań PostgreSQL, ale jeśli wiesz wystarczająco dużo, aby napisać taki sam, prawdopodobnie nie będzie on zbyt różny od tego, co zrobili. I wiesz, naprawdę nie jest tak trudno napisać podstawowy.

Ken
źródło
Z połączonego artykułu Joela o ciągach C nie wynika, że ​​następujący fragment prowadzi do niezdefiniowanego zachowania: char * str = "* Hello!"; str [0] = strlen (str) - 1; str jest literałem łańcuchowym i jest ogólnie w pamięci tylko do odczytu. Nie możesz na to pisać :?
HeretoLearn
Profesjonalny ekspert w dziedzinie baz danych, w porządku, ale każdy programista ?
Ben Aston,
Ben: Każdy profesjonalny programista, który często korzysta z baz danych, tak. Naprawdę nie są takie trudne, więc jeśli nie wiesz, jak to zrobić, oznacza to, że nigdy nie poświęciłeś trochę czasu na naukę działania DB. Każdy kierunek informatyki, który ukończyłem, zaprojektował procesor i wdrożył system operacyjny. Baza danych jest prostsza niż którakolwiek z nich, więc jeśli poświęcisz jej czas, nie widzę usprawiedliwienia dla niewiedzy o tym, jak działają.
Ken
2

Ważna jest kolejność kolumn w indeksie nieunikalnym.

Pierwsza kolumna powinna być kolumną o największej zmienności treści (tj. Liczności).

Ma to na celu ułatwienie SQL Serverowi tworzenia przydatnych statystyk dotyczących używania indeksu w czasie wykonywania.

Mike D.
źródło
-1 Nie jest dobrym pomysłem stosowanie się do zasad takich jak „Pierwsza kolumna powinna być kolumną o największej zmienności treści”. Jeśli ktoś ma podstawową wiedzę o tym, jak działają indeksy, można po prostu zobaczyć, jak ważna jest kolejność i że kolejność kolumn powinna zależeć od sposobu zapytania do tabeli.
miracle173
dzięki, ale jeśli indeks został utworzony na 3 polach, na podstawie tego, że określone zapytanie sql użyje tych 3 pól w klauzuli where, wówczas kolejność może być znacząca, a pole o największej liczności pojawiające się jako pierwsze \ wcześniej może prowadzić do poprawy wydajności .... lub przynajmniej to, co przeczytałem w książce dostrajania wydajności Microsoft SQL Server. Wypróbowałem to i wydawało się, że działa lepiej (lata temu).
Mike D
2

Poznaj narzędzia, których używasz do programowania bazy danych !!!

Zmarnowałem tyle czasu, próbując zrozumieć, dlaczego mój kod w tajemniczy sposób zawodzi.

Jeśli na przykład używasz platformy .NET, musisz wiedzieć, jak prawidłowo używać obiektów w System.Data.SqlClientprzestrzeni nazw. Musisz wiedzieć, jak zarządzać swoimi SqlConnectionobiektami, aby mieć pewność, że są one otwierane, zamykane i, jeśli to konieczne, odpowiednio usuwane.

Musisz wiedzieć, że kiedy używasz, musisz SqlDataReadergo zamknąć osobno SqlConnection. Musisz zrozumieć, jak zachować otwarte połączenia, gdy jest to właściwe, i jak zminimalizować liczbę trafień do bazy danych (ponieważ są one stosunkowo drogie pod względem czasu przetwarzania).

Daniel Allen Langdon
źródło
2
  • Podstawowe umiejętności SQL.
  • Indeksowanie
  • Zajmij się różnymi inkarnacjami DATE / TIME / TIMESTAMP.
  • Dokumentacja sterownika JDBC dla używanej platformy.
  • Obsługa binarnych typów danych ( CLOB , BLOB itp.)
JuanZe
źródło
1

W przypadku niektórych projektów model zorientowany obiektowo jest lepszy.

W przypadku innych projektów lepszy jest model relacyjny.

Mark Lutton
źródło
1

Problem niedopasowania impedancji i poznaj typowe niedociągnięcia lub ORM.

Muhammad Soliman
źródło
1

Kompatybilność z RDBMS

Sprawdź, czy konieczne jest uruchomienie aplikacji w więcej niż jednym systemie RDBMS. Jeśli tak, może być konieczne:

  • unikaj rozszerzeń RDBMS SQL
  • wyeliminować wyzwalacze i procedury przechowywania
  • przestrzegaj surowych standardów SQL
  • konwertuj typy danych pól
  • zmienić poziomy izolacji transakcji

W przeciwnym razie pytania te należy rozpatrywać osobno i opracować różne wersje (lub konfiguracje) aplikacji.

Juliano
źródło
1

Nie zależą od kolejności wierszy zwracanych przez zapytanie SQL.

Agnel Kurian
źródło
3
... chyba że zawiera ORDER BYklauzulę?
Aaronaught
I nie używaj ORDER BYniepotrzebnie, ponieważ powoduje to obciążenie serwera SQL
Vivian River