Robię własny komunikator i zastanawiam się czy warto jest użyć ORMa do takiego projektu. Problem jest taki, że nie mam dużego doświadczenia w aplikacjach z ORM, kiedyś napisałem klika projektów, ale nie były one używane produkcyjne, zrobione tylko dla przećwiczenia tego zagadnienia. W pracy też nie ma nikogo kto znałby znał się na ORM. Chciałbym użyć w firmie czegoś nowego, a możliwe jest, że dostanę pozwolenie na użycie takiego frameworka. Teraz nie wiem czy warto się za niego brać czy lepiej odpuścić, mimo że jest to niewielka aplikacja.
0
0
1)Jakie frameworka konkretnie?
2)Jeśli aplikacja jest nie wielka czy to ma sens? Generalnie narzędzi nie stosujemy "bo sa dla nas fajne" tylko dlatego że są dobre w tym kontekście.
0
A w jaki sposob chcesz wykorzystywac baze danych przy komunikatorze? Moze lepiej nosql?
0
scibi92 napisał(a):
1)Jakie frameworka konkretnie?
2)Jeśli aplikacja jest nie wielka czy to ma sens? Generalnie narzędzi nie stosujemy "bo sa dla nas fajne" tylko dlatego że są dobre w tym kontekście.
- Pewnie Hibernate
- Chciałbym ten projekt szybko zakończyć, zresztą taką też dostałem informacje z góry. Ciężko jest mi teraz ocenić czy użycie orma przyspieszy mi wykonywanie tego projektu. Może właśnie lepiej i szybciej będzie pisać sql, osadzać je w kodzie i samemu sobie mapować to na obiektu.
0
Bia napisał(a):
A w jaki sposob chcesz wykorzystywac baze danych przy komunikatorze? Moze lepiej nosql?
Typy baz nosql są mi obce, słyszałem co nieco o nich, ale nie używałem ich w praktyce. Czy do takiego komunikatora można by użyć bazy dokumentowej?
0
To zależy ile masz tabel , i ogólnie struktury. W sumie Hibernate cięzki bardzo nie jest do podstawowych zastosowań ;)
0
Ja nie kumam za bardzo.
W bazie chcesz trzymać historię rozmów czy coś jeszcze ?
Możesz poczytać:
https://www.quora.com/What-is-the-best-database-for-a-realtime-chat-server
https://www.quora.com/What-is-Slacks-architecture
0
Cza napisał(a):
Ja nie kumam za bardzo.
W bazie chcesz trzymać historię rozmów czy coś jeszcze ?Możesz poczytać:
https://www.quora.com/What-is-the-best-database-for-a-realtime-chat-server
https://www.quora.com/What-is-Slacks-architecture
Nie tylko rozmowy, dodatkowo z jednej strony chatu będą konsultanci, trzeba ich też jakoś przypisać do zagadnienia na jakim się znają. Poza tym rozmowy po zakończeniu mogą być oceniane. Coś się pewnie jeszcze znajdzie.
0
scibi92 napisał(a):
To zależy ile masz tabel , i ogólnie struktury. W sumie Hibernate cięzki bardzo nie jest do podstawowych zastosowań ;)
Max wyjdzie z 12 tabel z czego jedynie najwięcej operacji będzie na tej od rozmów, pokoi i ocen do rozmów.
0
No dobra no jest nie aż tak mało. Generalnie zalecam stragię miesznia Hibernate z SQL (np. przed JDBCTemplate), Hibernate ułatwi znacznie zapis/aktualizacje do bazy danych. To jest jakaś aplikacja webowa rozumiem? Jaka to architektura rozwiązania ma być?
0
Jeżeli nie wiesz co robić, to dobry moment by pobawić się w rozwiązanie kombinowane.
W komunikatorach dane można podzielić na dwie grupy. Pierwsza są to rzadko zmienne informacje o użytkownikach, kontaktach itp. Druga to dane rozmów. Pierwsza grupa jest idealna dla bazy relacyjnej, ponieważ w tego typu bazy zostały pomyślane by przechowywać tego rodzaju dane. Druga grupa, to dane dla bazy dokumentowej, albo wręcz plikowej.
zobacz jak to @jarekr000000 opowiada:
0
a tak w zasadzie to... czemu nie można skorzystać z gotowego rozwiązania? ;)
0
Chciałbym ten projekt szybko zakończyć, zresztą taką też dostałem informacje z góry. Ciężko jest mi teraz ocenić czy użycie orma przyspieszy mi wykonywanie tego projektu.
Może właśnie lepiej i szybciej będzie pisać sql, osadzać je w kodzie i samemu sobie mapować to na obiektu.
Jeśli znasz SQL, a nie znasz ORMa to raczej szybciej to napiszesz w SQL. ORMa będziesz musiał się uczyć, a to nauka (i research) zwykle zajmuje o wiele więcej czasu w projektach niż samo zaklepanie jak się wie co i jak. Nawet jak ORM ci przyśpieszy tworzenie apki, to ci ją opóźni o czas, który będziesz poświęcał na naukę ORMa.
Podobnie jest ze wszystkim, np. z frameworkami. Pisanie w nieznanym frameworku i nauka na bieżąco rzadko kiedy przyśpieszy tworzenie aplikacji, a zwykle ją tylko opóźni (co nie musi być wcale wadą. czasem warto opóźnić projekt po to, żeby skorzystać ze sprawdzonego lepszego rozwiązania. No ale "to zależy").