[JAVA] Eenvoudige databaseapplicatie met ODBC mogelijkheden

[Verwijderd]

Beste ontwikkelaars,

Ik moet een eenvoudige databaseapplicatie schrijven die ongeveer uit slechts een vijftal tabellen zal bestaan met zeer eenvoudige relaties. Nu kan ik dat natuurlijk doen in Microsoft Access, maar dan beperk ik mij naar mijn gevoel te veel voor wat betreft schaalbaarheid. Mijn idee is nu om de applicatie te schrijven in Java, maar er is één vereiste waar aan voldaan moet worden. De database moet benaderbaar zijn via ODBC, zodat bepaalde externe, van ODBC gebruik makende, applicaties er gegevens uit kunnen halen.

Is het, gegeven deze vereiste, aan te raden om iets te gaan doen met Java? Is er bijvoorbeeld een 'lightweight' Java RDBMS beschikbaar die ik kan gebruiken als de database achter de applicatie en die het ook mogelijk maakt om er een ODBC verbinding mee op te zetten?

Alvast bedankt!

[Verwijderd]

Wat natuurlijk ook altijd mogelijk is:
De database ontwikkelen in Microsoft Access en de GUI schrijven als een Java applicatie die een verbinding onderhoudt met de Microsoft Access database. De database kan dan probleemloos via ODBC worden benaderd door externe applicaties.

Of is het onzin om de GUI in deze opstelling te schrijven in Java en deze niet gewoonweg onder te brengen in de Microsoft Access database zelf?

[GrooV]

Java -> MySQL. Is ook gewoon benaderbaar via ODBC en zo hou je het nog gratis ook

[Verwijderd]

GrooV schreef op zaterdag 29 september 2007 @ 14:11:
Java -> MySQL. Is ook gewoon benaderbaar via ODBC en zo hou je het nog gratis ook

Nadeel is alleen wel, dat er een 'complete' MySQL server moet gaan draaien, terwijl je met bijvoorbeeld een Microsoft Access database kunt volstaan met enkel een bestand dat wordt benaderd.

[SeatRider]

Verwijderd schreef op zaterdag 29 september 2007 @ 14:28:
[...]

Nadeel is alleen wel, dat er een 'complete' MySQL server moet gaan draaien, terwijl je met bijvoorbeeld een Microsoft Access database kunt volstaan met enkel een bestand dat wordt benaderd.

Met ODBC niet zonder meer dacht ik. Zul je denk ik eerst MDAC voor moeten installeren, en of het dan nog gaat werken op niet-Windows clients betwijfel ik.

[blaataaps]

Al eens naar sqlite gekeken?

[Verwijderd]

blaataaps schreef op zaterdag 29 september 2007 @ 14:36:
Al eens naar sqlite gekeken?

Ik heb even meer informatie over SQLite opgezocht en ik moet zeggen dat dat wel eens heel interessant kan zijn. Er is ook een SQLite ODBC driver beschikbaar, dus dat lijkt ook goed. Ik ga mij er eens in verdiepen. Thanks voor de tip .

[Verwijderd]

blaataaps schreef op zaterdag 29 september 2007 @ 14:36:
Al eens naar sqlite gekeken?

Oke super! Ik heb succesvol een testopstelling kunnen maken, waarbij mijn Java applicatie probleemloos mijn SQLite database kan benaderen over ODBC :D! Nogmaals dank!

[Verwijderd]

Waar ik trouwens nog wel eens benieuwd naar ben, is het volgende. Zoals ik in de openingspost al opmerkte, voel ik er weinig voor om een Microsoft Access database te gebruiken en al helemaal, wanneer daarmee ook de GUI wordt ontwikkeld, zodat je één blok databaseapplicatie krijgt.

Maar is deze afkeer terecht? Microsoft Access wordt best veel gebruikt, dus in bepaalde opzichten zal het wel degelijk een goede, zo niet de beste, keuze zijn.

Wat zijn nu eigenlijk de voor- en nadelen van Microsoft Access?

[ZanomiX]

Verwijderd schreef op woensdag 03 oktober 2007 @ 20:05:
Waar ik trouwens nog wel eens benieuwd naar ben, is het volgende. Zoals ik in de openingspost al opmerkte, voel ik er weinig voor om een Microsoft Access database te gebruiken en al helemaal, wanneer daarmee ook de GUI wordt ontwikkeld, zodat je één blok databaseapplicatie krijgt.

Maar is deze afkeer terecht? Microsoft Access wordt best veel gebruikt, dus in bepaalde opzichten zal het wel degelijk een goede, zo niet de beste, keuze zijn.

Wat zijn nu eigenlijk de voor- en nadelen van Microsoft Access?

De korte ontwikkel tijd is meestal een zeer groot voordeel, zeker in samenwerking met VBA.

[Boss]

Je kan Access prima splitsen in front en back-end. Op die manier kan je (afhankelijk van hoe netjes je het programma verder opzet) tot ongeveer 10 gelijktijdige gebruikers aan in het programma. Dat zijn dan gebruikers die regelmatig data zoeken en bewerken. Zijn het minder actieve gebruikers dan kan je er nog verder mee gaan.

Wil je verder groeien, dan kan je de back-end (data) overzetten naar SQL Server (Express, gratis of de volledige). Dan gebruik je Access alleen als front-end. Op dat moment is het aantal gelijktijdige gebruikers een beperking van je databaseserve, en niet meer van Access.

De voordelen van Access is ongetwijfeld de korte ontwikkeltijd, terwijl je (als je er een beetje handig in bent) er ook heel ver mee kunt gaan qua complexiteit en samenwerking met andere programma's.

Een voor/nadeel is ook dat gebruikers soms ook Access kennis hebben en daarmee zelf rapportages kunnen maken van de database.

Nadeel is de licentiekosten. Veel gebruiken hebben geen Office Professional en dus geen Access. Dat moet je dan weer bijkopen.

[MisterBlue]

Een ander probleem met access is dat het zowel een eindgebruikers applicatie is als ontwikkeltool en dat het onderscheid tussen beide rollen niet altijd even duidelijk is.

Als ontwikkeltool mis ik dat je versie beheer kunt gebruiken op je modules en dat de logica op verschillende plekken (form, macro, vba of sql) verborgen kan zitten. Zeker als de applicatie door een ander geschreven is ben je even aan het zoeken hoe het in elkaar zit.

Je hebt ook geen simpele xUnit framework om test driven development te doen, maar je kunt wel makkelijk vanuit een module en vanuit de debugger test first werken. Maar dat is dan ook voor de echte TDD verslaafden.

Blijft natuurlijk dat je een applicatie met vijf tabellen tien keer zo sneller af hebt als in java.

[Apache]

Een sqllite achtige db, maar volledig in java geimplementeerd: http://hsqldb.org/

[Verwijderd]

Bedankt voor de zeer nuttige reacties!

Oke, Access kent een aantal aantrekkelijke voordelen, maar op de één of andere manier staat het mij wat tegen. Ik denk niet dat het verstandig is om een Access databaseapplicatie te ontwikkelen, wanneer te verwachten valt, dat deze op korte termijn na implementatie periodiek uitgebreid moet worden en uiteindelijk mogelijk moet gaan werken binnen een webomgeving. Waarom daar nu al niet op inspelen, door een meer dynamische technologie toe te passen?

Of heb ik gewoon een te negatief beeld van Access?

[Boss]

Al het programma 'uiteindelijk' moet gaan werken in een webomgeving, dan zou je dus nu al je hele applicatie in een web-geschikte taal (asp, php, ...) moeten maken.

Ik denk dat je ook even een goed onderscheid moet maken tussen je database (waar de data in staat) en de applicatie (wat de gebruiker voor zich ziet). Access als database kan je goed gebruiken en later makkelijk doorschalen naar SQL Server. Access als applicatie zit je vast aan een aantal beperkingen.

Je kan het Access project ook als prototype zien, die je de komende tijd actief gebruikt en verbeteringen in maakt. Heb je eenmaal de functionaliteit helemaal scherp, dan is dat een mooi moment om opnieuw te beginnen en dan in een web-omgeving.

[JKVA]

Boss schreef op woensdag 10 oktober 2007 @ 10:23:
Al het programma 'uiteindelijk' moet gaan werken in een webomgeving, dan zou je dus nu al je hele applicatie in een web-geschikte taal (asp, php, ...) moeten maken.

Ik denk dat je ook even een goed onderscheid moet maken tussen je database (waar de data in staat) en de applicatie (wat de gebruiker voor zich ziet). Access als database kan je goed gebruiken en later makkelijk doorschalen naar SQL Server. Access als applicatie zit je vast aan een aantal beperkingen.

Je kan het Access project ook als prototype zien, die je de komende tijd actief gebruikt en verbeteringen in maakt. Heb je eenmaal de functionaliteit helemaal scherp, dan is dat een mooi moment om opnieuw te beginnen en dan in een web-omgeving.

En het gaat toch over Java, dus als je Hibernate gebruikt in je DAO's, kun je relatief gemakkelijk van DBMS switchen. Alleen dialect en wat DB specifieke zaken veranderen.