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.

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!

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.

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.

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.

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.

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ć.

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.

Unikanie wstrzykiwania SQL i jak zabezpieczyć bazę danych

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ść.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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).

• 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.)

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

W przypadku innych projektów lepszy jest model relacyjny.

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

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.

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

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/