Dlaczego Derby i MySQL jedyne RDMBS, które bierzesz pod uwagę? Jeśli powiesz Derby , powinieneś sprawdzić HSQLDB , H2 , SQLite również. Jeśli powiesz MySQL , powinieneś sprawdzić Postgres również (która ma o wiele więcej funkcji).
To tylko nazwa niektórych darmowych RDBMS. Oczywiście, jak już to ujął Charlie, jest wiele innych i wiele powodów, aby pójść w którąkolwiek stronę. Sprawdź tę (doskonałą IMO) stronę porównawczą w Wikipedii, gdzie znajdziesz zalety i ograniczenia dowolnych RDBMS:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
Jeśli chodzi o Twoje wymagania dotyczące „pobieralności” Twojej aplikacji internetowej, możesz oczywiście osadzić RDBMS (dowolny z Derby, H2, HSQLDB) w swojej aplikacji internetowej. Ale możesz też po prostu skonfigurować MySQL lub Postgres lub jakąkolwiek inną integrację i dać swoim pobierającym instrukcje, jak samodzielnie skonfigurować swoją aplikację internetową. W końcu, gdy używasz skonfigurowanego w kontenerze DataSource
dla Twojej aplikacji internetowej, tę konfigurację można łatwo wykonać.
Teraz, nawet jeśli uważasz, że stworzenie aplikacji internetowej z wbudowaną bazą danych może być łatwiejsze, powinieneś zawsze myśleć o krok do przodu. Pytania takie jak:
- Czy będziesz w stanie połączyć się bezpośrednio z tą bazą danych, aby łatwo poprawić niespójności danych? (To przydarzy się nam wszystkim)
- Czy będziesz w stanie łatwo zmienić schemat?
- Czy będziesz w stanie łatwo wykonać kopię zapasową swoich danych?
- itd. itp... jest też więcej pytań dotyczących konserwacji
Ponieważ Twoje komentarze sugerują, że Twoje dane rosną z czasem i powinny się utrzymywać, nie wybrałbym wersji osadzonej, ale trzymaj dane oddzielnie od aplikacji. Pamiętaj, że nie wyklucza to Derby z projektu Twojej aplikacji. Oznacza to po prostu, że musiałbyś uruchomić Derby jako samodzielny serwer.