Czy zadaniem programistów jest zaprojektowanie bazy danych?

Byłem programistą przez ostatnie sześć lat. Przez całą swoją karierę pracowałem nad wieloma aplikacjami internetowymi.

Przez większość czasu, kiedy potrzebna była baza danych, była ona przekazywana nam (programistom) lub mieliśmy trochę starszej bazy danych do pracy. Jeśli nie, musieliśmy samodzielnie stworzyć i zaprojektować bazę danych, co nie było trudne.

Ale czy jako programiści mamy stworzyć całą bazę danych od zera, gdy musimy zbudować nową aplikację, w której dane są tak ważne i mają skomplikowane wymagania związane ze złożonym modelem danych?

Czy to nie leży w najlepszym interesie aplikacji i firmy, aby zrobić to ekspert?

Nie próbuję uciec od projektowania bazy danych, ale jest to bardzo ważne, aby dobrze się postarać.

Przede wszystkim to twoja praca, jeśli kierownik projektu ci to powie. Mniejsze firmy często nie mają pełnoetatowych ekspertów ds. DB. W każdym razie nie ma (i nie powinno być) wyraźnego rozróżnienia między programistami a ekspertami DB - każdy dobry programista będzie miał znaczną wiedzę na temat DB, a każdy dobry DBA będzie wiedział, jak kodować, przynajmniej w języku DB dla procedur przechowywanych .

Chociaż konstrukcja DB jest dość centralną częścią aplikacji, nie jest ważniejsze „poprawne” niż inne centralne części, od których będzie zależeć wiele innych kodów.

I podobnie jak kod, pomysł, że masz super-eksperta, który usiądzie i zastanowi się przez tydzień, a następnie zapisze idealny projekt, którego nigdy nie będzie trzeba zmieniać, jest iluzją. Projekt DB może i będzie się zmieniać w miarę opracowywania aplikacji.

Dlatego tak naprawdę korzystne jest zaprojektowanie DB przez programistę (który dobrze rozumie DB), ponieważ wtedy masz kogoś, kto zna obie strony. To z pewnością lepsze niż zrobienie tego przez kogoś, kto rozumie tylko DB i nie ma nic wspólnego z resztą prac programistycznych.

Programiści często tworzą bazę danych. Bardzo powszechne. Niestety wielu programistów nie ma doświadczenia z DB. Nie rozumieją, jak raportować w odniesieniu do dużych zbiorów danych, koncepcji rzutników danych, schematów gwiazd itp. Niektórzy nawet nie rozumieją podstaw normalizacji.

Jeśli jeden człowiek ma umiejętności robienia wszystkiego na poziomie eksperckim, stanowi to bardzo dobry produkt. Armia jednoosobowa może zrobić to, co może zrobić drużyna 10-osobowa w ułamku czasu z 1000-krotną jakością. Bez przesady.

W najlepszym interesie programisty jest zrobienie tego (mniej osób), zakładając, że programista wie, co robi. Oczywiście są też tysiące błędów, na które można wskazać.

To interesujące pytanie - istnieje mocny argument, że większość porządnych programistów powinna zrozumieć, jak prawidłowo zbudować relacyjną bazę danych, to znaczy, że powinni być w stanie wytworzyć znormalizowany schemat i - w oparciu o doświadczenie i wspólne wzorce - uzasadnić decyzje dotyczące sposobu przechowywania danych (według mnie jest to oczywiste, ale wiem, że nie wszyscy tak to widzą).

Ponadto, jeśli spojrzysz na Entity Framework Code-first, co sugeruje, że ta sama myśl, która dotyczy budowy niskiego poziomu modelu danych, da rozsądny schemat - lub przynajmniej wskazówkę.

Więc nie, nie sądzę, że potrzebujesz eksperta od bazy danych, aby zaprojektować schemat bazy danych - przynajmniej nie dla małych i średnich baz danych (nad którymi pracowałem).

Problem polega na tym, że zaprojektowanie dobrego (lub przynajmniej odpowiedniego) schematu nie jest całą historią - zwłaszcza jeśli baza danych musi być skalowana. Wydaje mi się, że „wartością dodaną” przyniesioną przez DBA jest poprawne indeksowanie rzeczy, innych niż podstawowy schemat - indeksowanie, konfigurowanie pamięci masowej, utrzymanie bazy danych (kontrola rozmiarów plików, przebudowywanie indeksów itp.), Bycie mądrzejszym z użytkownikami i rolami itd.

Dobry programista powinien przynieść różnorodne portfolio umiejętności - powinien być czymś więcej niż koderem [wstaw język wyboru] i chciałbym uwzględnić zrozumienie baz danych w tym portfolio.

Myślę, że umiejętność zaprojektowania rozsądnej relacyjnej bazy danych jest zasadniczo niezbędna dla nie-młodszych programistów.

Mając to na uwadze, szczególnie w przypadku dużych aplikacji, bardzo ważne jest, aby baza danych była „poprawna” za pierwszym razem (schemat, indeksowanie itp.). Jeśli firma ma dostęp do wykwalifikowanego DBA, to zadanie powinno spaść na ich talerz; ogólnie będą bardziej wykwalifikowani. Potencjalny przegląd / dyskusja powinna zostać przeprowadzona z głównym programistą, który będzie uzyskiwał dostęp do bazy danych i pracował z nią po stronie klienta, aby nie było niespodzianek. Jeśli nie ma DBA, programista projektuje bazę danych.

Widzę tutaj dwa pytania:

• Czy programiści baz danych powinni modelować logikę biznesową?
• Czy powinienem wiedzieć, jak utrwalić dane w bazie danych?

Logika biznesowa

• Logika biznesowa nie istnieje w bazie danych. To model koncepcyjny, który musi być niezależny od innych warstw w twoim systemie.

• Zawsze możesz zastąpić jedną bazę danych inną, a nawet zdecydować się na zastosowanie rozwiązań NoSQL w celu rozwiązania potencjalnych problemów z wydajnością.

• Twórcy baz danych mogą być zaangażowani w proces modelowania, ale zwykle robią to ludzie z pełnym zrozumieniem problematycznej dziedziny. W naszej organizacji robią to programiści po stronie serwera.

• Wielu uważa, że ​​baza danych jest podstawą twojej aplikacji. Zrób złe podstawy, a system upadnie. Nie zgadzam się z tym. Widzę bazę danych jako nośnik pamięci, który zawsze można wymienić.

Trwałe dane

• Powinieneś wiedzieć, jak utrwalić dane na różnych nośnikach pamięci, w tym na rozwiązaniach SQL i NoSQL.

• Poziom wymaganej wiedzy specjalistycznej będzie się różnić w zależności od wielkości systemu, nad którym pracujesz.

• Małe firmy oczekują od ciebie tej wiedzy, podczas gdy większe firmy zwykle zatrudniają ekspertów w celu spełnienia wymagań dotyczących wydajności, skalowalności i bezpieczeństwa.

Podsumować:

• Model domeny jest podstawą twojego systemu, a nie bazy danych.

• Jeśli pracujesz dla małej firmy przy stosunkowo małym projekcie, prawdopodobnie powinieneś sam zaprojektować bazę danych.

• Jeśli pracujesz dla dużej firmy w systemie korporacyjnym, prawdopodobnie bardziej sensowne jest przekazanie pracy ekspertom w tej dziedzinie.