Najpierw kod a baza danych


77

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



6
@gnat: To jest zupełnie inne.
Robert Harvey

1
Jeśli zostanie ono zamknięte jako duplikat, powinno być duplikatem tego pytania . Odpowiedzi i pytania są bardziej zgodne z tym, o co pytam.
RubberDuck,

1
@Mawg to projekt roboczy. Odepchnąłem tyle, ile tylko mogłem, aby spełnić wymagania. Prace muszą się nad tym rozpocząć i nic więcej nie mogę na to poradzić.
RubberDuck,

4
Errrm, nowa praca? Wiem, że tak. Ale jako 30-letni freelancer uważam, że łatwo jest odejść, zanim naprawdę trafi do wentylatora (niektórzy ludzie po prostu nie mogą pomóc), ale zdaję sobie sprawę, że nie jest to takie łatwe dla wszystkich. Zostań, jeśli musisz (żaden porównywalny pracodawca w okolicy itp.), ale nie zostań, jeśli zacznie to na ciebie wpływać
Mawg

Odpowiedzi:


85

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


1
„Baza danych jest szczegółem”. Dziękuję bardzo za link. Z całego serca wierzę, że po obejrzeniu tego przemówienia będę mógł poradzić sobie z tym projektem, pozostawiając bazę danych jako odroczoną decyzję.
RubberDuck

6
I po prostu nazwijmy to: wszystkie te praktyki (prawdopodobnie te ) są ważnymi praktykami w rozwoju Agile (programowanie przyrostowe, najprostsza rzecz, która może działać, testowana, użytkownik potrzebuje najpierw ...).
sleske,

8
Chciałem wrócić i jeszcze raz podziękować. Cała moja środkowa warstwa działa bez bazy danych i teraz doskonale rozumiem, jak dane powinny być utrwalane. Nie mogę ci wystarczająco podziękować. Głosowałbym ponownie, gdybym mógł.
RubberDuck

12
Jeśli naprawdę uchwycisz wszystkie wymagania za pomocą metody opartej na kodzie i naprawdę wyrazisz wszystkie te wymagania w ostatecznej bazie danych , mogę zgodzić się z tą odpowiedzią. Ale widziałem wiele, wiele projektów, w których satysfakcja z uzyskania czegoś „działającego” powoduje, że „jeśli to działa, baza danych musi być wystarczająco dobra”, nawet jeśli jest to STRASZNY projekt bazy danych, z nieuniknionymi i poważnymi problemami z wydajnością później. Ponadto wydaje się, że wiele osób myśli, że jeśli kod sprawdza poprawność danych, których nie potrzebujesz ograniczeń CHECK lub FOREIGN KEY. Robisz .
Ross Presser,

2
Możliwe, że jest to omówione w filmie - niestety nie mogę teraz do tego dojść - ale kolejną zaletą podejścia przyrostowego jest to, że poprawnie wykonane pomaga utrwalić niejasne specyfikacje. „Czy ten ekran wygląda tak, jakby przechwytywał wszystkie potrzebne informacje kontaktowe? Czy pola są ułożone w kolejności zgodnej z przebiegiem pracy?” Zdolność zadawania tych pytań - z czymś konkretnym jako odniesieniem - jest często jedynym sposobem na uzyskanie potrzebnych informacji.
David

17

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.


Zgadzam się z całego serca, ale w tym przypadku tak się nie stanie. Dziękuję za poświęcony czas.
RubberDuck,

9
Jeśli nie masz czasu, aby zrobić to dobrze, gdzie znajdziesz czas, aby to zrobić?
Walter Mitty,

Kto powiedział coś o tym, że nie zrobił tego dobrze @WalterMitty? Proszę zobaczyć link wideo w zaakceptowanej odpowiedzi. Baza danych jest szczegółem , który nie musi być na miejscu, aby obsłużyć 95% oprogramowania.
RubberDuck,

1
Uznałem, że „tak się nie stanie”, co oznacza, że ​​przystąpisz do kodowania nawet bez pojęcia, jakich informacji potrzebują interesariusze z systemu. Myślę, że James dał ci bardzo dobrą radę na temat przeprowadzania podstawowej analizy systemów bez popadania w paraliż analizy.
Walter Mitty,

Źle mnie zrozumiałeś @WalterMitty. Podjąłem podejście pętli sprzężenia zwrotnego. Zbuduję to, co moim zdaniem powinno (bez bazy danych), a następnie przekażę to użytkownikom. Zmodyfikuj program. Powtarzać. Po kilku iteracjach powinienem dokładnie wiedzieć, jak będzie wyglądać baza danych. Jak rozumiem, podejście zwinne jest specjalnie zaprojektowane, aby sprostać niejasnym wymaganiom. Widzę to dobrze w tym projekcie.
RubberDuck,

12

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.


To są wszystkie bardzo prawdziwe rzeczy, aw rzeczywistości to będzie być zastąpienie „non-Process” i arkusza kalkulacyjnego, ale nie udało mi się zobaczyć, jak to jest odpowiedź na moje pytanie. Czy możesz wyjaśnić?
RubberDuck

1
@ RubberDuck Na końcu mojej odpowiedzi dodałem wyjaśnienie.
Tulains Córdova,

11

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.


Właśnie tak zwykle pracuję. Najpierw wymagania , tak. Jak chciałbym, mógłbym teraz wyciągnąć od kogoś pewne solidne wymagania.
RubberDuck,

Wymagania pierwszy, choć nie należy czekać aż wymagania są kompletne (nigdy nie są). Zacznij już wtedy, gdy będziesz miał dość pojęcia, jakie są cele aplikacji, a potem zdobądź więcej, gdy będziesz ich potrzebować.
sleske,

@sleske - Dobry analityk powinien wyczuć bardziej „dynamiczne” (tj. niejasne i zmienne) części wymagań i zapewnić pewną elastyczność w projekcie, aby łatwo poradzić sobie z zachciankami użytkowników.
James Anderson,

1
@JamesAnderson: W rzeczywistości jestem wielkim fanem zwinnych zasad programistycznych, w których zwykle projektujesz tylko to, czego potrzebujesz teraz , chyba że wiesz, że nie możesz później zmienić projektu (rzadko tak jest). Ale zaczynam odchodzić od tematu ...
sleske

8

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.


3
+1 ani dla „najpierw kod”, ani „najpierw baza danych”, ale „najpierw niedziałający prototyp gui” (inaczej „szybkie prototypowanie”), ponieważ przy braku wymagań prototyp gui pomaga wyjaśnić wymagania użytkownikom końcowym.
k3b

1
To prawda, ale pozwala im również wierzyć, że aplikacja jest tak dobra, jak zrobiona. Byłem tak spalony wcześniej i teraz
żądam, abyśmy spełnili

@Mawg tak, niestety jest to niebezpieczeństwo. Jedną z opcji (przynajmniej w Javie) jest użycie dziwnego „wyglądu i działania”, aby wyjaśnić, że jest to prototyp.
user949300,

Jeśli nie wiesz, dokąd zmierzasz, dowolny kod cię tam zaprowadzi.

-1

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.


W ten sposób leży szaleństwo. Nigdy nie utrwalaj danych, dopóki nie będziesz gotowy, aby je utrwalić. Normalizacja danych po fakcie jest koszmarem.
RubberDuck,

1
Istnieje różnica między uporczywością a normalizacją. Pytanie, na które tylko ty możesz odpowiedzieć, to czy muszę tylko upierać się, czy też utrzymywać i normalizować. Model danych to model, jeśli nie ma żadnych wymagań, trudno jest modelować coś relacyjnie.
Jon Raynor,

-2

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


3
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami poczynionymi i wyjaśnionymi w poprzednich 5 odpowiedziach
gnat

Chodzi mi o podejście zgodne z typem klienta
Kein IhpleD,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.