Witam

Już niedługo stanę przed napisaniem swojej pracy dyplomowej. Na dzień
dzisiejszy musze wymyślić temat mojego projektu.

Jako że swoją przyszłość chciałbym związać z programowaniemw Javie
przymierzam się do napisania aplikacji bazodanowej (z wykorzystaniem
transakcji itp.) w tejże technologii. Problem w tym, że w Javie jestem
jeszcze zielony. Dopiero zaczynam swoją przygodę z tym językiem. Mam
co prawda doświadczenie z takimi językami jak Pascal, Object Pascal, C
oraz C++.

Moje pytania są następujące:


1) Jakiej technologi użyć Db4o, Hibernate, JPA (może coś innego)?
2) Jaki SZBD (PostgreSQL czy MySQL)?
3) Może istnieje jakaś inna lepsze technologia - jeśli tak to proszę o
komentarz
4) Może ktoś mógłby mnie zainspirować innym tematem lub jego
rozwinięciem - bo wydaje mi się że taki projekt może być mało ambitny.

Wszelkie opinie mile widziane.

Pozdrawiam

Marcin Olszówka wrote:
> 2) Jaki SZBD (PostgreSQL czy MySQL)?

A dlaczego nie możesz robić czegoś uniwersalnego? Co będzie działać z
dowolną bazą?

> 3) Może istnieje jakaś inna lepsze technologia - jeśli tak to proszę o
> komentarz
> 4) Może ktoś mógłby mnie zainspirować innym tematem lub jego
> rozwinięciem - bo wydaje mi się że taki projekt może być mało ambitny.

Zależy co ma robić aplikacja. Może to być duży CRM, jak i podręczny
zbiór adresów. Jeśli chcesz coś ambitnego, to niech użytkownik może
definiować tabele i logikę biznesową.
Ew. możesz się pobawić w javaMyAdmin :)

wer

pon, 22 lut 2010 o 12:31 GMT, Marcin Olszówka napisał(a):

> Jako że swoją przyszłość chciałbym związać z programowaniem w Javie
> przymierzam się do napisania aplikacji bazodanowej (z wykorzystaniem
> transakcji itp.) w tejże technologii.

Mona zstawierdzic ze 99% aplikacji EE jest takich, tzn bazodanowych z
wykorzystaniem transakacji, wiec to standard

> Moje pytania są następujące:
>
> 1) Jakiej technologi użyć Db4o, Hibernate, JPA (może coś innego)?

Jezeli dopiero zaczynasz i nie masz doswiadczenia, to wybralby, to co jest
najpopularniejsze, czyli to gdzie uzyskasz najwiecej pomocy...

db4o jest fajny pomysl, ale ma tez duuze ograniczenia, i nie widzialem
jakiegos wsparcia w framerowkach

Hibernate mozna odkreslic nadzbiorem JPA, zreszta jak bedziesz uzywac JPA,
to i tak w 90% przypadkach bedzie to Hibernate

> 2) Jaki SZBD (PostgreSQL czy MySQL)?

Przy wykorzystaniu ORM jest to prawie bez znaczenia, niemniej polecam
zawsze Posgresqla zamiast Mysqla, zamiast tego mozesz jeszcze pomyslec nad
MS sql server/DB2/Oracle w wersjach "Express", sa duzo przyjazniejsze w
administracji dla osob nieobeznanych...

> 3) Może istnieje jakaś inna lepsze technologia - jeśli tak to proszę o
> komentarz

Musisz, a raczej powinienes wybrac sobie jakis szkielet aplikacj, polecam
albo Spring albo Seam

> 4) Może ktoś mógłby mnie zainspirować innym tematem lub jego
> rozwinięciem - bo wydaje mi się że taki projekt może być mało ambitny.
>
> Wszelkie opinie mile widziane.

Mozesz tez zamiast strikte javy, zainteresowac sie Groovym i Grailsem, albo
jeszcze Scala i Liftem..., np. wtedy wymyslic sobie np. nawet bardzo prosty
projekt, ale jako temat pracy zrobic: "Wykorzystanie jezyka funkcyjnego do
tworzenia aplikacji webowych", wtedy mozesz porownac jave ze scala itp...


Pozdrawiam
Brzezi

Brzezi pisze:
> polecam
> zawsze Posgresqla zamiast Mysqla

a dlaczego?

MZ pisze:
> Brzezi pisze:
>> polecam
>> zawsze Posgresqla zamiast Mysqla
>
> a dlaczego?

Bo ma lepszą licencję?
Bo jest bardziej w głownym nurcie? Bo te doświadczenia sa bardziej do
powielenia (np. na Oraclu).
Bo mniej wiąże z egzotyczną specyfiką? Mo ma sprawdzone od wielu wersji
transakcje, triggery, view ?
Bo mysql wprowadzając w/w cechy mocno stracił (i tak dawno nieoczywistą)
przewagę szybkościową?

jak widac wybrał bym tak samo. (Ze wzgl praktycznych też dużo mam Javy
nad MS-SQL, co ktos tu proponował)

MZ wrote:
> Brzezi pisze:
>> polecam
>> zawsze Posgresqla zamiast Mysqla
>
> a dlaczego?

Zaczyna się kolejna święta wojna :-)

http://dev.mysql.com/doc/refman/5.5/...e-trigger.html
"Currently, triggers are not activated by cascaded foreign key actions.
This limitation will be lifted as soon as possible"

pon, 22 lut 2010 o 15:01 GMT, MZ napisał(a):

> Brzezi pisze:
>> polecam
>> zawsze Posgresqla zamiast Mysqla
>
> a dlaczego?

Nie wiem jak jest teraz dokladnie, tzn wiem ze mysql poczynil znaczne
postepy, ale za dawniejszych czasow(wcale nie tak daleko w przeszlosc),
mysql nie nadawal sie do profesjonalnych zastosowan... z pstgresqlem mam
dobre doswiadczenia, z mysqlem mam male, dlatego polecam to co w moim
przekonaniu jest godne polecenia...

Pozdrawiam
Brzezi

Jacek Czerwinski pisze:
> Bo jest bardziej w głownym nurcie? Bo te doświadczenia sa bardziej do
> powielenia (np. na Oraclu).
> Bo mniej wiąże z egzotyczną specyfiką?

można prosić o jakieś konkrety?

MZ pisze:
> Jacek Czerwinski pisze:
>> Bo jest bardziej w głownym nurcie? Bo te doświadczenia sa bardziej do
>> powielenia (np. na Oraclu).
>> Bo mniej wiąże z egzotyczną specyfiką?
>
> można prosić o jakieś konkrety?

Specyficzne bool-e, pola bitowe - to co zapamietalem, sporo drobiazgów
naprawde nisko przenośnych. nawet sam autonum miły ale bardzie
specyficzny niż w głownym strumieniu.


Dodam: Nieco hackerska atmosfera skupiona na szczegół a nie ogół, jak
wiedza który indeks jest lepszy a który gorszy.

Skojarzenie z problemami ze stronami kodowymi (może z akcentem na soft PHP).

> Skojarzenie z problemami ze stronami kodowymi (może z akcentem na soft
> PHP).

potwierdzam teoretycznie wysoką problematyczność z kodowaniem /
collation baz na mysql. O ile mamy admina który wie co robi jest ok, ale
jeżeli chcemy mieć kilka baz wielojęzycznych z różnym collation to
prostszy wybór to postgresql (mniejsze ryzyko problemów). W przypadku
wybrania typu InnoDB odpada kilka problemów ktore jak dla mnie
dyskwalifikuja ta baze + typ MyISAM w użyciu korporacyjnym (sławne
"table is marked as crashed and should be repaired") ale w powszechnym
mniemaniu tabele InnoDB (ACID) są wolniejsze niż Postgresql.
Niebagatelne znaczenie ma coraz większa kompatybilność Postgreql z
Oracle (wpływ enterprisedb)

"MZ" <matt_z> wrote in message
news:uep1
> Jacek Czerwinski pisze:
>> Bo jest bardziej w głownym nurcie? Bo te doświadczenia sa bardziej do
>> powielenia (np. na Oraclu).
>> Bo mniej wiąże z egzotyczną specyfiką?
>
> można prosić o jakieś konkrety?
>

Strona z opisem zaskakujących właściwości MySQL. Ciekawa lektura:
http://sql-info.de/mysql/gotchas.html
Dla PostgreSQL też jest, ale znacznie krótsza:
http://sql-info.de/postgresql/postgres-gotchas.html

Pozdrawiam
Jarek

"Marcin Olszówka" <divisionone777> wrote in message
news:7e7c
[..]
>
> 1) Jakiej technologi użyć Db4o, Hibernate, JPA (może coś innego)?
> 2) Jaki SZBD (PostgreSQL czy MySQL)?
> 3) Może istnieje jakaś inna lepsze technologia - jeśli tak to proszę o
> komentarz
> 4) Może ktoś mógłby mnie zainspirować innym tematem lub jego
> rozwinięciem - bo wydaje mi się że taki projekt może być mało ambitny.
>
> Wszelkie opinie mile widziane.
>

Moja opinia jest taka, że w pracy dyplomowej trzymaj się daleko od takich
tematów. Znajdź coś niebanalnego, może coś z dziedziny AI, uczenia
maszynowego, komputerowej analizy tekstów, grafiki 3d czy czegokolwiek
innego. Jak chcesz javę, to zawsze możesz to w javie zaimplementować.
Aplikacje tzw. "bazodanowe" będziesz pewnie potem tłukł w pracy,
przynajmniej na początku - będziesz miał dość.
Jak już ktoś tu kiedyś pisał, praca dyplomowa to może być ostatnia okazja do
napisania czegoś ciekawego i pasjonującego ;-)

Pozdrawiam
Jarek

Jarek pisze:

> Moja opinia jest taka, że w pracy dyplomowej trzymaj się daleko od
> takich tematów. Znajdź coś niebanalnego, może coś z dziedziny AI,
> uczenia maszynowego, komputerowej analizy tekstów, grafiki 3d czy
> czegokolwiek innego. Jak chcesz javę, to zawsze możesz to w javie
> zaimplementować.
> Aplikacje tzw. "bazodanowe" będziesz pewnie potem tłukł w pracy,
> przynajmniej na początku - będziesz miał dość.
> Jak już ktoś tu kiedyś pisał, praca dyplomowa to może być ostatnia
> okazja do napisania czegoś ciekawego i pasjonującego ;-)


Bardzo dobra myśl. Ostatnia okazja bardzo często.

MZ wrote:
>> Bo mniej wiąże z egzotyczną specyfiką?
> można prosić o jakieś konkrety?

Klient mysql od wersji 5.0.51b uważa, że poniższa linia nie stanowi komentarza w skrypcie SQL:
--komentarz

Popełnia tym samym błąd odstępstwa od specyfikacji języka SQL i dodatkowo uniemożliwia sam sobie
wczytanie dumpów bazy zrobionej mysqldump 5.0.51b ;-)))

Jak to zobaczyłem to najpierw nie mogłem uwierzyć a później straciłem ostatnie przyjazne uczucia do
tej bazy danych.

Postgresql kładzie MySQL na łopatki pod każdym względem, jeśli rozmawiamy w kontekście
poważniejszych aplikacji (a nie hello world czy 'kalendarz na zaliczenie').