Wszędzie tam gdzie są problemy wydajnościowe, tylko baza danych sobie może z tym poradzić i jej mechanizmy czyli Oracle;)
Owszem - wszędzie tam i tylko tam. A czy Oracle, czy inna, to jest akurat odrębny temat.
nie neguję, w końcu procedury składowane też można uznać za 3 warstwę.
Raczej nie bardzo. Trzy warstwy polegają na oddzieleniu GUI, logiki biznesowej i składowiska danych.
przy dużych projektach nie robi się takich zmian, to ma działać latami - to są fabryki, a nie blogi;)
Wiadomo, że jeśli istnieje sobie aplikacja, która ma 100 lat i ona działa, to nikt nie będzie tego przepisywał od zera na nowsze technologie, bo to nie ma sensu. Ale to nie znaczy, że działające latami aplikacje wymagają upychania logiki w bazie, bo tak nie jest.
a dlaczego wszyscy mają się zajmować wszystkim? wystarczy że są ludzie od logiki biznesowej, ludzie od bazy danych i ludzie od interfesu użytkownika? czy się mylę?;)
Przy zdrowym podejściu jest taki podział, ale przy upychaniu logiki w procedurach składowanych, SQL jest wszystkim, więc wszyscy muszą go znać na niezłym poziomie.
tak nie stosuje tych mechanizmów, ale pytanie czy bez tego da się nie żyć? i czy przy wszytkich rodzajach projektów jest to niezbędne? - raczej nie...
Oczywiście, że nie są niezbędne. Tak samo jak nie są niezbędne tablice, pętle czy instrukcje warunkowe. A jednak ułatwiają pracę i pozwalają pisać mniej kodu.
nie chodzi mi o to, że jakaś funkcja robi wszystko, chodzi mi ogólnie o to, że w tym modelu (MVC) piszesz masę kodu, który normalnie jest nie potrzebny ( w bazie )
Co to znaczy "normalnie"? Ten kod jest potrzebny aby zachować przejrzystą strukturę aplikacji z wyraźnym podziałem odpowiedzialności, zapewnić łatwość testowania oraz modyfikacji i debugowania. Kod pisze się przede wszystkim po to, aby inni ludzie mogli go czytać i modyfikować.
Ponadto, sam język pozwala Ci napisać mniej kodu niż SQL, i nawet z tym narzutem powodowanym przez MVC, finalnie jest go mniej.
tematyka którą się zajmuję nie wymaga takowych futerow;) - po prostu narzedzie jest dobrane do specyfikacji projektu.
Tematyka nie jest ważna, dzielenie kodu na funkcje i moduły to podstawa pisania czytelnego kodu, niezależnie od języka.
wszystko zależy od projektanta...
Owszem, jeśli projektant nie spieprzy na dzień dobry wpychając całej logiki do bazy, to szanse na upadek projektu maleją. To, że tak się robiło 30 lat temu, to nie jest argument, bo jakoś sporo z tych aplikacji już nie istnieje, właśnie dlatego, że nie dało się ich rozwijać.