Czy zawsze trzeba zaczynać projekt aplikacji od UML i C#, czy naprawdę nie można od strony bazy SQL?

Nauczyciel skrytykował mój projekt aplikacji bazodanowej i chcę Was zapytać, czy miał rację.
Mam fajnie opracowany projekt bazy w SQL i interfejs w C#.
Jednak nauczyciel powiedział, że rozpoczęcie projektu aplikacji od nawet najpiękniej znormalizowanej bazy danych jest BŁĘDEM.
Dlaczego? Ponieważ może się okazać, że nie ze wszystkich tabel będziemy korzystać :(.
Najpierw mam określić funkcjonalności aplikacji za pomocą UML, potem na podstawie "ludków" opracować interfejs i na końcu założyć ewentualne tabele w SQL.

I co ważne, wszelkie obliczenia, aplikacja ma przeprowadzać w C#, a nie funkcjami i procedurami w SQL.
Nauczyciel powiedział wręcz, że dokonywanie obliczeń z poziomu SQL, to błąd metodologiczny, ponieważ funkcje i procedury w SQL wykonują - oprócz tych moich - niewidoczne dla usera czynności (ciekawe jakie?), które suma sumarum składają się na zbyt duży koszt czasowy przeprowadzanych obliczeń. Liczyć ma się w C#, a w bazie ma być jak najmniej przechowywanych danych - tylko to, czego nie da się wyliczyć w C#.

Powiedzcie proszę, zgadzacie się z nauczycielem? (podkreślone zdania)

Pozdrawiam, z ciekawością czekam na Wasze opinie.

Ja bym zaczął od programu, a nie od bazy. I niekoniecznie z użyciem UML-a.

Bo czy baza jest w ogóle potrzebna? Jeśli tak, to jaka? Dlaczego chcesz zaczynać od bazy, która jest tylko mechanizmem przechowywania danych? Jakich danych? Skoro jeszcze nie wiesz co program robi, to skąd wiesz jakie baza musi mieć tabele?

Tworzysz jakiś program, a baza jest tylko jednym z jego elementów. Nie buduj programu jako jedynie otoczki wokół Bazy, traktowanej w roli “god object”.

Zarowno pomysl klepania najpierw bazy, jak i klepania najpierw UMLi jest slaby. Glownie dlatego, ze ludzie, ktorzy znaja sie na tym co piszesz nie znaja sie na jednym ani drugim. Dlatego sie uzywa koslawych rysunkow na tablicach/kartkach do projektowania. Potem mozna jechac z UMLem, ale tez nie jest to jedyne wyjscie, bo mozna po prostu spisac use-case/user-story na kartkach i zaczac klepac kod.

Problem bazy jest taki, ze najlepiej o niej zapomniec ;)
Natomiast problemem UMLi jest to, ze nikomu sie nie chce tego rysowac, o aktualizowaniu juz nie wspominajac.

Jeśli chodzi o projekt to zgadzam się z n0name_l.

Jeśli chodzi o obliczenia na bazie to trzeba je wykonywać tak dużo jak się da - ale nie więcej.
Co to oznacza?

Z jednej strony obliczenia (w tym funkcje) na bazie pozwalają na przemielenie bazy bez potrzeby jej przetwarzania kursorowego.
Jeśli rekordy masz i tak wszystkie (lub większość) przeczytać, to lepiej zrobić to po stronie klienta bazy (C#).
Ale jeśli masz wybrać tylko podzbiór rekordów na podstawie jakiegoś warunku który może być obsłużony przez funkcję SQL to takie zapytanie będzie szybsze - ze względu na to że nie musisz pobierać wszystkich rekordów przez sieć (lub interfejsy).

Jeśli natomiast masz coś przetworzyć kursorowo (rekord po rekordzie) w procedurze składowanej lub funkcji to wygodniej to zrobić po stronie klienta - ale tylko ze względu na architekturę aplikacji (ja preferuję trzymanie logiki aplikacji po stronie klienta bazy - łatwiej znaleźć kogoś kto zna np. C# niż kogoś kto biegle implementuje procedury T-SQL).
Ale nawet przetwarzanie kursorowe nadal będzie szybsze po stronie bazy. No chyba że robisz jakieś naprawdę skomplikowane algorytmy w rodzaju data mining domowym sposobem.

Procedury składowane, funkcje i widoki (logika po stronie bazy) są też stosowane gdy trzeba zinterfejsować dwa systemy przez bazę danych.

Z całkowitą rezygnacją z przetwarzania po stronie bazy spotkałem się tylko na mainframe gdzie system miał być dostępny nawet gdy wykonywało się przetwarzanie po całej bazie.
Wtedy potrzebne dane wyciągało się z bazy do pliku, przetwarzało COBOL-em i ładowało wynik z powrotem.
Przy takim przetwarzaniu po całej bazie nawet ORDER BY jest nie polecany.

Rimmel napisał(a):

Nauczyciel skrytykował mój projekt aplikacji bazodanowej i chcę Was zapytać, czy miał rację.
Mam fajnie opracowany projekt bazy w SQL i interfejs w C#.
Jednak nauczyciel powiedział, że rozpoczęcie projektu aplikacji od nawet najpiękniej znormalizowanej bazy danych jest BŁĘDEM.
Dlaczego? Ponieważ może się okazać, że nie ze wszystkich tabel będziemy korzystać :(.
Najpierw mam określić funkcjonalności aplikacji za pomocą UML, potem na podstawie "ludków" opracować interfejs i na końcu założyć ewentualne tabele w SQL.

Oczywiście, że zanim zacznie się tworzyć aplikację, najpierw trzeba określić, co ta aplikacja ma robić. Zaczyna się od wymagań funkcjonalnych, a nie od bazy.

W UML ludki nie służą do opracowywania interfejsu, ale właśnie do specyfikacji wymagań funkcjonalnych przy pomocy diagramów przypadków użycia.

Gdy już mamy wymagania, i wiemy, co chcemy zrobić, możemy sobie opracować diagram ERD i zrobić bazę danych. Ale to jest podejście nieefektywne. Szybciej jest napisać aplikację, a bazę danych wygenerować sobie na podstawie klas aplikacji. Zresztą, w początkowej fazie tworzenia aplikacji, baza danych może nie być w ogóle potrzebna. Klientowi pokazuje się prototyp, który danych nigdzie nie zapisuje, dopiero jak klient powie, że mu się to podoba, można pomyśleć o tym, jakiej bazy użyć.

I co ważne, wszelkie obliczenia, aplikacja ma przeprowadzać w C#, a nie funkcjami i procedurami w SQL.
Nauczyciel powiedział wręcz, że dokonywanie obliczeń z poziomu SQL, to błąd metodologiczny, ponieważ funkcje i procedury w SQL wykonują - oprócz tych moich - niewidoczne dla usera czynności (ciekawe jakie?), które suma sumarum składają się na zbyt duży koszt czasowy przeprowadzanych obliczeń. Liczyć ma się w C#, a w bazie ma być jak najmniej przechowywanych danych - tylko to, czego nie da się wyliczyć w C#.

Kod po stronie serwera bazy danych jest:

1. Trudny do testowania - nie ma mowy o testach jednostkowych, TDD jest niemożliwe, frameworki do testów są słabe.
2. Trudny do logowania. Zapis do pliku z bazy jest trudny i niewydajny, do loga systemowego ograniczony, itp.
3. SQL jest bardzo rozwlekły przy typowych obliczeniach.
4. SQL, w przeciwieństwie do języków obiektowych, nie pozwala na wyrażanie abstrakcji.
5. SQL ma bardzo ubogą bibliotekę funkcji i procedur.
6. SQL pozwala na ograniczoną rekurencję, nie ma pętli ani tablic.
7. To wszystko sprawia, że SQL powoduje dużą nadmiarowość kodu.
8. Po prostu - SQL to język do manipulowania danymi, a nie do obliczeń czy logiki biznesowej.

Generalnie pisanie w SQL to okradanie siebie z czasu i klienta z pieniędzy oraz odwrotnie. Procedury mają sens jedynie przy dokonywaniu operacji manipulowania dużymi ilościami danych, np. zmiana wartości jakiejś kolumny dla setek czy tysięcy rekordów jakiejś tabeli.

1. Tworzenie bazy przed ogarnięciem wymagań aplikacji? o_O To jakiś dziwny pomysł. Często przecież nawet architekturę aplikacji ciężko zaprojektować "z góry", a co tu dopiero mówić o strukturze bazy danych, która przecież jest zwykle nieistotnym szczegółem, który generuje się przy pomocy ORMa. W czasie pisania aplikacji te klasy encyjne zapewne ulegną zmianie jeszcze 100 razy, pewne pola dojdą, inne wypadną, pojawią się nowe tabele, inne znikną. Podsumowując: tak, nauczyciel ma racje (co warto cenić, bo niewielu prowadzących zna sie na tym co wykłada ;) )
2. Jak juz wspomniano wyżej: procedury wart stosować tylko w bardzo określonych sytuacjach - kiedy daje to wyraźny zysk wydajnościowy i jest potrzebne. W innym wypadku utrudnia to analizę systemu, debugowanie i wprowadzanie zmian. Nie wspominam nawet o tym co by się działo przy stawianiu u klienta nowej wersji aplikacji ;] Klienci zwykle nie są specjalnie chętni żeby ktoś im gmerał ręcznie w bazie ;)

Jeśli natomiast masz coś przetworzyć kursorowo (rekord po rekordzie) w procedurze składowanej lub funkcji to wygodniej to zrobić po stronie klienta - ale tylko ze względu na architekturę aplikacji

Zgadza się. Zapytanie SQL powinno ograniczać ilość pobieranych danych - zarówno wierszy jak i kolumn, czyli unikać select *, ale logika aplikacji, czyli jakieś obliczenia na tych danych, powinny być po stronie C#.

Azarien, n0name_l, vpiotr, somekind, Shalom
(in order of apearrance ;))
wielkie dzięki Chłopaki za tak szybki odzew! I tyle porad!

@Azarien
Chyba chwytam ideę: wziąć się za program, nie marnować czasu na przymiarki w UML'u, bo i tak wszystko wyjdzie w trakcie ;)
Tak, baza (SQL) jest potrzebna, bo muszę ewidencjonować dane (rozchód) z pokwitowań na papierze.
Aplikacja później sobie z tych stanów liczy różne rzeczy.
Stąd łatwiej mi było zacząć od bazy, bo ona odzwierciedla dane z kwitków.

@n0name_l
"Natomiast problemem UMLi jest to, ze nikomu sie nie chce tego rysowac, o aktualizowaniu juz nie wspominajac."
@Azarien
"ideą UML-a miało być, że jest zrozumiały dla każdego - a więc i dla zleceniodawcy - w przeciwieństwie do kodu. jednak zbytnia formalizacja sprawiła, że na UML-u trzeba się „znać”, więc nie spełnił pierwotnych założeń."

Święte słowa!! W praktyce i tak każdy najpierw robi program, a potem dla świętego spokoju robi "tego UML'a", żeby nie urazić nauczyciela - przypomina mi to sytuację z podstawówki, gdy nauczycielka nam robiła kartkówki z plastyki, bo komuś nieopatrznie się wymsknęło, że plastyka do niczego w życiu nam się nie przyda... :D

@vpiotr, @somekind
Ależ ogromna dawka wiedzy! Muszę dobrze przemyśleć to, co napisaliście i przeczytać jeszcze z kilka razy, żeby niczego nie uronić.

@Shalom
Przyznaję rację, że faktycznie lepiej zacząć od strony aplikacji.
Tak jak piszesz, "klikanie na ekranie" i jak w końcu uzyskamy to, co chcemy, to generujemy ORM'em strukturę bazy danych.
Ale UML, to myślę, że dla wielu praca odtwórcza - program już powstał, ale robimy UML'a, by zadowolić nauczyciela.
Albo żeby zleceniodawca był pod wrażeniem "fachowej" dokumentacji.

W ogóle, to chylę czoła przed Waszą wiedzą.
Niesamowicie szybko piszecie, temat niełatwy, a Wy formułujecie zdania tak lekko, jakbyście pisali o kobietach ;)

Jeszcze raz dzięki ogromne za Wasze wypowiedzi.
Spokojnej nocy, Panowie.

Ale UML, to myślę, że dla wielu praca odtwórcza - program już powstał, ale robimy UML'a, by zadowolić nauczyciela.

Z tym UMLem, nawet już po napisaniu aplikacji, to nie do końca tak jest. Bo UML ma też służyć przyszłym programistom we wdrażaniu się w projekt. Niestety bardzo często projekty mają marną / znikomą dokumentację i bardzo trudno sie w nich odnaleźć. Jak coś jest małe to spoko, ale jak ma > 1kk linii kodu to nie da się "ogarniać" takiego kodu skacząc po klasach.