@somekind:
Jeśli chodzi o czas wytworzenia, to taka Java (EE, spring, jpa/hibernate, angular od frontu etc.) jest najwolniejszą techologią z jaką miałem do czynienia.
0
0
A kiedy korzystałeś ostatni raz ze Springa i z jakich modułów? Korzystałeś ze Spring Data JPA?
To takie proste! Te dwa światy też są proste do połączenia w jednej aplikacji, sam to robiłem wielokrotnie.
Parafrazując, miło mądrego poczytać :)
0
Moje doświadczenie z Java i Spring jest znikome. Moje doświadczenie w produkcji dużych systemów dla biznesu jest spore. Ta sama funkcjonalność wyprodukowana przez zespół od Java wymaga więcej czasu niż przez zespół związany z inną techologią. I nie, nie jestem przeciwnikiem Java, ORM itp.. Take są moje spostrzeżenia co do szybkości tworzenianaplikacji JEE.
1
I jeszczw raz. Moim zdaniem ORM jest fajną techologią. Nie zgadzam się jednak absolutnie, że dzięki ORM znajomość SQL staje się niepotrzebna. Jak na razie bez SQL w dużych aplikacjacj klasy enterprise się zwyczajnie nie da.
0
A kto w ogóle napisał że SQL
- Nie warto się uczyć
- W dużych aplikacjach się nie przydaje?
Bo ja pisałem wielokrotnie że korzystam z SQL nieraz natywnie (przez JdbcTemplate)
0
Wielu tak powiedziało/napisało, także na tym forum. Widzę, że mamy podobne zdanie, więc nie podyskutujemy.
1
hyde napisał(a):
@somekind:
Jeśli chodzi o czas wytworzenia, to taka Java (EE, spring, jpa/hibernate, angular od frontu etc.) jest najwolniejszą techologią z jaką miałem do czynienia.
Mnie niekoniecznie o JEE chodziło, ale wierzę. Podobna sytuacja zdarza się też w świecie .NET. Programiści i architekci klasy enterprise lubią skomplikowane mechanizmy, więc dodają wiele bezużytecznych warstw abstrakcji oraz technologie zabijające wydajność. Wtedy faktycznie rzeczy, które powinny być szybkie już takie nie są. Sam kiedyś zostałem zmuszony do pisania przy użyciu ORMa raportów. Z jednym z nich męczyłem się ze 3 dni próbując zmusić EF do połączenia danych z kilku złączeń opatrzonych różnymi warunkami w jedną odpowiedź. Ostatecznie się nie udało, musiałem wykonać kilka oddzielnych zapytań, a potem połączyć je w jeden wynik już po stronie aplikacji. W sumie to miało jakieś 500 linijek kodu C#. W SQL to samo zapytanie miało ok. 20 (a ekspertem nie jestem).
Gdzie sens? Gdzie logika? No, ale architekt kazał, więc trzeba było rzeźbić.
Natomiast w niepatologicznym i zdroworozsądkowym przypadku, tworząc najpierw aplikację można napisać kod wykonujący wszystkie algorytmy i przepływy oraz testy dowodzące jego poprawności. Nie trzeba mieć całej działającej aplikacji wraz z powolną bazą danych aby sprawdzić wszystkie algorytmy. Nie trzeba mozolnie klikać w GUI, a potem dłubać w SQL, aby odnaleźć błędy. To znacznie zwiększa ogólną produktywność - jeśli używa się tego dobrze.
A mając napisaną aplikację i ORMa bazę danych po prostu można wygenerować.
A SQL, przynajmniej podstawowo znać trzeba. Choćby po to, aby móc ocenić, czy ORM nie oszukuje albo nie przesadza.
6
Prawda jest taka że wiele osób ma klapki a oczach i stosuje klasyczne podejście z młotkiem. Tzn jeśli masz młotek to nagle wszystko wygląda jak gwoździe. ORM nie jest ani lepszy ani gorszy od innych rozwiązań. Tak samo jak SQL nie jest ani lepszy ani gorszy od noSQL. Każde z nich ma swoje zastosowania w których sprawdza się dobrze, ale są też takie w których będzie się sprawdzać źle. Zadaniem programisty jest rozumieć kiedy i czego używać.
Niczym nie różni się to od takich podstawowych kwestii jak korzystanie choćby ze struktur danych. Programista powinien rozumieć kiedy użyć List a kiedy HashSet, a nie narzekać że wyszukuje sobie elementów w liście i mu się program strasznie ślimaczy i te listy to w ogóle są głupie i nie warto ich używać (dokładnie takie argumenty widzę w tym wątku :D).
Myślcie czasem o tym, że rzadko kiedy w informatyce jest jakiś silver bullet czy jakieś panaceum. Dobierajcie narzędzia do potrzeb!
0
A kiedy NoSQL jest lepsze od SQL?
0
scibi92 napisał(a):
A kiedy NoSQL jest lepsze od SQL?
Pewnie wszędzie tam gdzie kupienie większego serwera jest kosztowniejsze niż kupienie dodatkowych serwerów.
https://www.brianjgraf.com/2013/05/17/scalability-scale-up-scale-out-care/
0
Shalom napisał(a):
Prawda jest taka że wiele osób ma klapki a oczach i stosuje klasyczne podejście z młotkiem. Tzn
jeśli masz młotek to nagle wszystko wygląda jak gwoździe. ORM nie jest ani lepszy ani gorszy od innych rozwiązań. Tak samo jak SQL nie jest ani lepszy ani gorszy od noSQL. Każde z nich ma swoje zastosowania w których sprawdza się dobrze, ale są też takie w których będzie się sprawdzać źle. Zadaniem programisty jest rozumieć kiedy i czego używać.
Niczym nie różni się to od takich podstawowych kwestii jak korzystanie choćby ze struktur danych. Programista powinien rozumieć kiedy użyć List a kiedy HashSet, a nie narzekać że wyszukuje sobie elementów w liście i mu się program strasznie ślimaczy i te listy to w ogóle są głupie i nie warto ich używać (dokładnie takie argumenty widzę w tym wątku :D).Myślcie czasem o tym, że rzadko kiedy w informatyce jest jakiś silver bullet czy jakieś panaceum. Dobierajcie narzędzia do potrzeb!
Niestety królują dwa podejścia:
Albo legacy-syf albo hype driven development. Trudno o coś po środku.
0
scibi92 napisał(a):
A kiedy NoSQL jest lepsze od SQL?
Wtedy kiedy "wyrastasz" z tego co SQL oferuje. Przykładowo, potrzebujesz bazy grafowej, a SQLowe JOINY i RECURSIVE CTE jest już za wolne. Innym przykładem jest Cassandra, którą Amazon stworzył by mieć pewność, że rzeczy, które zapisałeś w koszyku w tym koszyku są, ale niekoniecznie odczyt się uda. Większość NoSQLi ma swoje (wąskie) zastosowania, tylko z niewiadomych powodów HypeDD powoduje, że ludzie zaczynają ich używać tam gdzie to nie ma najmniejszego sensu.
0
A kiedy NoSQL jest lepsze od SQL?
NoSQL to nie jest jednolite podejście więc pytanie jest trochę bez sensu.
Niemniej masz np. takie rzeczy jak bazy grafowe (np. punkty mapy wpisane do bazy i szukasz ścieżek) do których SQL się nijak nie nadaje, masz key-value store, które też bez sensu imitować SQLem, masz bazy dokumentowe które trudno byłoby SQLem zasymulować...