Najpierw kod a baza danych

Kiedy projektuję i tworzę oprogramowanie, nad którym pracuję, zwykle najpierw projektuję i tworzę tabele SQL zaplecza, a następnie przechodzę do właściwego programowania. Projekt, nad którym obecnie pracuję, wprawił mnie w zakłopotanie. Wynika to prawdopodobnie z braku dobrych, solidnych wymagań, ale tym razem niewiele mogę zrobić. Jest to sytuacja typu „po prostu idź, żeby się stało”, ale dygresuję.

Zastanawiam się nad odwróceniem przepływu pracy i stworzeniem klas interfejsu użytkownika i modelu danych w nadziei, że wypracowanie tego pozwoli mi wyjaśnić, jak ostatecznie będzie wyglądał mój schemat bazy danych. Czy to dobry pomysł? Denerwuję się, że skończę z interfejsem użytkownika i nadal nie mam pojęcia, jak ustrukturyzować bazę danych.

Jeśli ktoś jest ciekawy, używam programu SQL Server jako zaplecza, a MS Access jako aplikacji front-end. (Dostęp też nie jest moim wyborem ... więc proszę, nie nienawidzę go zbyt źle.)

Co było pierwsze, proces lub dane wykorzystane przez ten proces? Wiem, że jest to pytanie typu „kurczak lub jajko”, ale w przypadku oprogramowania uważam, że jest to proces.

Na przykład, możesz stopniowo budować swój model danych, wdrażając pojedynczy przypadek użycia jednocześnie z trwałością w pamięci (lub czymkolwiek tak łatwym do wdrożenia). Gdy poczujesz, że zaimplementowałeś wystarczającą liczbę przypadków użycia do zarysowania podstawowych encji, możesz zastąpić trwałość w pamięci rzeczywistą bazą danych, a następnie kontynuować udoskonalanie schematu w miarę postępów, jeden przypadek użycia na raz.

Spowoduje to oderwanie się od bazy danych i przeniesienie jej do sedna problemu: reguł biznesowych. Jeśli zaczniesz od wdrożenia reguł biznesowych, w końcu dowiesz się (przy okazji procesu bardzo podobnego do selekcji naturalnej), które dane są naprawdę potrzebne firmie. Jeśli zaczniesz od modelowania bazy danych, bez informacji zwrotnej na temat tego, czy te dane są naprawdę potrzebne (czy w tym formacie, czy na tym poziomie normalizacji itp.), Albo skończysz robić wiele opóźnień w schemat (który może wymagać intensywnych procedur migracji, jeśli firma już z nim działa), lub będziesz musiał zaimplementować obejścia w regułach biznesowych, aby nadrobić niedostosowany model danych.

TL; DR: Baza danych zależy od firmy - jest przez nią zdefiniowana. Nie będziesz potrzebować danych, chyba że masz proces, który z nimi działa (raport jest także procesem). Najpierw zaimplementuj ten proces, a dowiesz się, jakich danych potrzebuje. Najpierw modeluj dane, a być może będziesz w stanie policzyć, ile założeń było błędnych podczas pierwszego modelowania.

Trochę poza tematem, ale bardzo ważne: opisywany przepływ pracy jest często stosowany wraz z bardzo ważnymi praktykami, takimi jak „Najprostsza rzecz, która mogłaby ewentualnie działać”, programowanie oparte na testach i skupienie się na oddzieleniu architektury od szczegółów, które wchodzić ci w drogę (wskazówka: baza danych). Co do ostatniego, ta rozmowa całkiem dobrze podsumowuje ten pomysł.

Analiza przyczyn źródłowych sugeruje, że problem ten nie dotyczy jednej metody, ale braku specyfikacji. Bez niego tak naprawdę nie ma znaczenia, co napiszesz najpierw - i tak to wyrzucisz.

Zrób sobie przysługę i dokonaj podstawowej analizy systemu - zidentyfikuj użytkowników na różnych poziomach, zrób szybki i brudny kwestionariusz, a następnie wyłącz maszynę, weź kawę i ciasteczka / pączki (lub cokolwiek innego, co nasmaruje koła), a następnie przejdź się ich biurka, zapytaj ich, co robią i co powinni wiedzieć / nagrywać, aby wykonywać swoją pracę, nawet jeśli wydaje się to oczywiste - wciąż pytaj. Nie martw się o to, jak ważni są, jeśli są zbyt zajęci, to umów się, aby wrócić innym razem lub zostawić je ze sobą.

Gdy już to zrobisz, powinieneś być w stanie zacząć budować wszystko, co według ciebie da najlepsze wyniki, i zaczekaj, aż pojawi się reszta specyfikacji.

Moje doświadczenie jest następujące:

• W większości projektów, nad którymi pracowałem, najpierw zaprojektowaliśmy bazę danych.
• Często dane już istnieją w arkuszach kalkulacyjnych, starszych bazach danych, w wersji papierowej itp. Dane te zawierają wskazówki na temat tabel, które należy przechowywać.
• Często proces jest już używany, ale ręcznie lub przy użyciu kilku różnych narzędzi, które nie są zautomatyzowane, nie współpracują i / lub nie są zgodne ze standardami.
• Gdy masz już częściowo dojrzały model bazy danych, możesz rozpocząć projektowanie prototypowych formularzy, okien itp., Które odczytują i zapisują dane w tej bazie danych.
• W dalszym ciągu konieczne będą pewne zmiany w celu uwzględnienia rzeczy, które na początku nie były rozważane.

Pamiętaj także:

• To już nie jest świat jednej aplikacji <-> jednej bazy danych. Być może Twoja aplikacja będzie musiała czytać lub zapisywać dane z więcej niż jednej bazy danych lub twoje rozwiązanie będzie obejmować więcej niż jedną aplikację korzystającą z tej samej bazy danych.

Wniosek: zalecam najpierw zaprojektować bazę danych.

Chciałem powiedzieć, że baza danych jest pierwsza, ponieważ mam duże doświadczenie w dużych projektach i naprawdę potrzebujesz solidnego modelu danych, jeśli masz wielu programistów pracujących równolegle.

Ale potem zastanowiłem się nad tym trochę i zdałem sobie sprawę, że to, co naprawdę robiliśmy przy bardziej udanych dużych projektach, to „wymagania przede wszystkim”.

Dobry, dobrze określony zestaw wymagań biznesowych, prowadzi do dobrego zestawu wymagań funkcjonalnych. Jeśli masz dobry zestaw wymagań funkcjonalnych, model danych i specyfikacje modułów po prostu mieszczą się w jednym miejscu bez większego wysiłku.

Ponieważ wydaje się to tak płynne / nieokreślone, najpierw wykonam interfejs GUI - to brzmi jak to, czego potrzebujesz, aby uzyskać odpowiedzi, wsparcie, czas i informacje zwrotne od interesariuszy, prawda? Nie dbają o twoje genialne znormalizowane tabele i ograniczenia kluczy obcych i kaskadowe usuwanie. Ale fajne GUI z dużą ilością błyszczących kolorów - cóż, to najwyższy poziom!

W przypadku początkowej bazy danych zaplecza użyj czegoś niezwykle prostego, na przykład kluczy / wartości zapisanych w pliku. Nie znam MS Access, więc nie wiem, jaki byłby „najlżejszy” backend. (stół rozkładany?) Cokolwiek jest szybkie i brudne, planuj je wyrzucić.

Jeśli możesz, użyj śmiesznego wyglądu w graficznym interfejsie użytkownika, aby wyjaśnić, że jest to prototyp. Jeśli wszystko inne zawiedzie, użyj kart indeksowych.

Być może twoi interesariusze są ekspertami od DB - czasami tak się dzieje ze mną! - w takim przypadku wykonaj kilka projektów DB.

Ponieważ wymagania nie są jasne, można zacząć od bardzo podstawowego modelu danych z kluczowymi elementami, o których będziesz wiedział, że potrzebujesz, być może po prostu podstawowych tabel i PK na początek. Reszta danych jest przekształcana do postaci szeregowej w formacie binarnym lub XML i na początku zapisuje BLOB w bazie danych. Powinno to pozwolić na opracowanie interfejsu użytkownika i warstwy biznesowej (warstwy środkowej) bez w pełni relacyjnego modelu, ale nadal będziesz musiał uporać się z zapisywaniem i odzyskiwaniem oraz prostymi kluczowymi przeglądami w razie potrzeby.

Na przykład, może masz Osobę, więc masz PK Identyfikatora Osoby. Reszta atrybutów nie jest znana, więc po prostu zacznij od tabeli Osoby z identyfikatorem osoby PK i kolejną kolumną, w której będzie przechowywany obiekt Blob, wszystkie dane osoby.

Po utrwaleniu wymagań weź swoje obiekty BLOB i wyodrębnij wszystkie potrzebne tabele i kolumny, aby uczynić model relacyjnym. Następnie wystarczy zmienić trwałość BLOBa na relacyjną w warstwie dostępu do danych. Ale wszystko inne, interfejs reguł biznesowych itp. Nadal będzie działać. Zauważ, że to dodaje trochę czasu do projektu, ale pozwala na całkowitą elastyczność dodawania i upuszczania rzeczy w razie potrzeby bez zmiany modelu relacyjnego, aż rzeczy staną się twardsze

Wyszukiwanie może być opóźnione, ponieważ nie można zapytać o BLOB, więc gdy model się ustabilizuje, zacznij przechowywać dane, które należy przeszukać w relacyjnych kolumnach.

Zasadniczo zaczynasz od modelu tabelarycznego i przechodzisz do modelu relacyjnego w miarę postępu projektu.

Lub też należy ustalić wymagania przed rozpoczęciem jakichkolwiek prac, aby na początku opracować model relacyjny.

Ogólnie myślę, że kod przychodzi po danych, ponieważ kod ma zamiar manipulować danymi.

Jeśli wymagania nie są jasne, możesz stworzyć model danych do interpretacji wymagań. Najlepiej może zapisać niektóre wymagania i wysłać je do swojego pracodawcy, a potem mają coś do zrobienia. Lub najpierw stwórz GUI, zależy to od rodzaju pracodawcy, który działa najlepiej :)