Cześć,
gdzie powinno się umieszczać zapytania do bazy? Czy jeśli uzywam jakiegoś ORMa to powinienem w kodzie aplikacji pisać zapytanie, czy umieszczac je w bazie w postaci funkcji/procedur i tylko w aplikacji odwoływać się do funkcji/procedur?
Uzywam C# i EntityFramework, ale to chyba nie ma znaczenia, bo pytanie dotyczy chyba różnych baz i języków programowania.
Jeżeli zapytanie jest duże i skomplikowane to szybciej wykona się jako obiekt bazodanowy (widok, procedura). Poza tym programista pisząc widok, procedurę ma wpływ na sposób wykonania złączeń i optymalizację.
W związku z tym wszystko zależy od efektu, który chcesz osiągnąć. Korzystając z ORM zyskujesz na szybkości pisania kodu, ale możesz stracić na szybkości pobierania danych z bazy.
Wszystko, co nie wymaga krytycznej wydajności lepiej tworzyć używając ORMa, bo oszczędność na czasie pisania kodu jest większa niż oszczędność na czasie wykonywania zapytań.
Najlepiej, jak masz porobione widoki w bazie danych, a w aplikacji odwołujesz się do tych widoków. Czasem są potrzebne procedury składowane. Zdecydowanie kod SQL na serwerze wykona Ci się szybciej niż analogiczny kod w Twojej aplikacji. Nie odnoszę się tu do ORM, bo nie o to pytasz.
Zależy jak duży to będzie system. Widziałem systemy z kilkoma tysiącami procedur w bazie i utrzymanie tego było koszmarem.
Kilka tysięcy procedur w bazie? Ktoś ostro pojechał...
Cool story ode mnie: Pracowałem przy jednym z największych, jeżeli nie największym polskim systemie ERP. Do każdej nowej tabeli utworzonej przez programistę lub wdrożeniowca generowało się automatycznie kilkadziesiąt obiektów bazodanowych (procedur, funkcji, triggerów), do tego programiści pisali kolejne procedury, które realizowały jakieś potrzeby biznesowe. W sumie procedur było dziesiątki tysięcy u jednego klienta (standard + wdrożeniowe + generowane automatycznie, z przewagą tych ostatnich), a w sumie u wszystkich klientów tego nikt nie jest w stanie policzyć. Jednak nikt nie narzekał na utrzymanie tej kobyły, ponieważ w bazie był system kontroli wersji i każdy obiekt (nie generowany automatycznie) był opisany, miał autora, wersję itd. Aplikacja kliencka obsługiwała wszystkie te obiekty na podstawie konfiguracji, tj nie trzeba było pisać kodu po stronie aplikacji dla każdej nowej tabeli, tylko ta tabela (wraz z obiektami wygenerowanymi automatycznie) była wczytywana przez aplikację na podstawie konfiguracji. Ogólnie cały system był bardzo fajnie pomyślany i na co dzień pracowało przy nim kilkudziesięciu programistów, którzy utrzymywali standard + kilkudziesięciu wdrożeniowców, którzy rozwijali i dostosowywali system u klientów.
Jedyną bolączką było to, że u niektórych klientów wdrożeniowcy tworzyli rzeźby czasami bardzo złożone, które funkcjonowały równolegle do standardu, ponieważ trzeba było szybko coś uruchomić u klienta i wdrożeniowcy nie mogli czekać na programistów, którzy napiszą i wprowadzą do standardu potrzebną funkcjonalność.