@kickfire: jak na własne potrzeby, spróbowałbym każdego z wymienionych przez Ciebie jak i kolegów języków.

Liczy się wynik i swoboda pracy.

Plusem skryptowych programów jest to, że nie kompilujesz tylko uruchamiasz ten skrypt (python, ruby, js, ps, ...) wydaje się najmniej wydajne ale rzeczywistość potrafi zaskoczyć. Musisz mieć zawsze środowisko uruchomieniowe, można popsuć program przezPokaż całość

@bbkon: ja używam VPS z ArubaCloud

@ludzik: wszystko zależy co chcesz osiągnąć,

where filtruje ci wyniki całego zapytania gdzie w większości przypadków jest dobre i normalne. przy zwykłym inner join działa jak ta lala.

Kiedy robisz np left outer join where może ci wyciąć wyniki, które chciałeś zobaczyć. Możesz ograniczać wyniki z poszczególnych tabel w warunku joina np ... tabela t1 left join tabela2 t2 on t1.id = t2.tid and t2.atrybut=5 bo jak zrobisz where poPokaż całość

@ludzik:to outera zrobisz, w mssql używało się *= lub =* lub *=* ale stary standard przed sql92 i raczej niemile widziane takie pisanie selectów
SELECT a.id, b.relid, c.relid
FROM
tabA a, tabB b, tabC c
WHERE a.id *= b.relid AND a.id *= c.relid

@DarkAlchemy: mam ciekawostkę z optymalizacji, ( ͡º ͜ʖ͡º) co powiesz by wyjaśnić dlaczego transactional log rośnie do niebotycznych rozmiarów, nawet dla bazy kilku megowej, wiadomo #mssql baza w trybie full recovery. Truncate nie robi roboty.

@DarkAlchemy: FullBackup jest robiony co 24h i niestety nie zmienia to wielkości pliku. Autogrowth jest ustawiony na przyzwoite wartości i po tyle wzrasta co jakiś czas.

Nie wiem, czy o nie ma związku z tym, że klient do bazy jest podłączony 24h/dobę.

Pomaga dopiero wykonanie przełączenia bazę w tryb Simple Recovery Model i ponowne przełączenia na Full Recovery Model powoduje, że popracuje kilkanaście-kilkadziesiąt dni i znowu mam zapełniony dysk. Myślałem,Pokaż całość

@DarkAlchemy: ok 300MB plik bazy a log urósł go ok 40GB w jednym przypadku, w drugim 45MB baza i log też potrafił urosnąć do 40GB. Obecnie obie pracuję w trybie Simple Recovery Model.

@mk321: Ręcznie, z reguły dostosowuję klienta (Hibernate) do bazy danych. Ewentualnie buduję odpowiedni view na potrzeby działania aplikacji lub stosuję Konwertery jak nie można inaczej.

no i używam spring.jpa.hibernate.ddl-auto=validate

@mk321: wszystko zależy, ogólnie z wydajnością nie ma problemu, silnik SQL jest dużo szybszy w operacjach jak Hibrnate, który zadaje multum podzapytań by zbudować drzewo obiektów. Więc osobiście wolę zbudować view (głównie do podglądu) zoptymalizować po stronie serwera i odczytać jak trzeba by biznes był zadowolony.

Co do pracy z modyfikacją danych lepiej zbudować Konwerter inaczej Adapter po stronie aplikacji, który zmapuje mi jeden obiekt na drugi używany w baziePokaż całość

@mk321: ogólnie jestem przyzwyczajony na przenoszenie pracy na serwer sql. To może być przyzwyczajenie/naleciałość z pracy przy budowaniu aplikacji stricte client-server, gdzie się teraz odchodzi od takiego modelu.

a jasne. Czyli w kodzie masz dwie warstwy. Entity, które jest bezpośrednim odzwierciedleniem bazy danych. Tego nie zmieniasz, chyba że zmieni się baza. I druga warstwa obiektów, na których rzeczywiście operujesz, wykonujesz logikę biznesową, zmieniasz je na własne potrzeby do funkcjonalności.

@mk321: dokładnie tak.

A co jak musisz wykonać jakieś bardziej skomplikowane rzeczy na bazie? Jakieś wyszukiwarki, joiny, update batchowe, kontrola transakcji itd. Na tych pośrednich klasach ciężko to robić i tłumaczyć.

Pokaż całość

@ugotowany_kamien: masz pokręcone w nawiasach

if exists (select jobid from employees where jobid like 'AD_PRES' and @jobid = 'AD_PRES')

@Nunino: ja również jestem po kursie sda.