I want to create a data management system which will be used via a GUI, by many users in different locations. I want to use client/server connections when a user logs into the GUI, and then whenever anything is added/updated, the database is updated accordingly. I am wondering firstly, if this architecture is logical and will work? And secondly, whether I need to store the database online, or if it can be stored locally and then accessed by people online using the GUI? The database is currently in MS Access however I can migrate to another program if it will make things easier.
I am doing the GUI in Java and will use JDBC to access the database.
There's no 'best' option, but a good solution would be to develop some web services that channel traffic to and from the database, then have your GUI call those web services.
That way you can control access far more easily, as well as ensuring data integrity by having the web service perform validation and sanity checks.
i would suggest you use mysql database your connection is something like this in java jdbc
Class.forName("com.mysql.jdbc.Driver");
// Setup the connection with the DB
connect = DriverManager
.getConnection("jdbc:mysql://remoteUri/database-name?"
+ "user=user&password=userpw");
Yes, it is possible. Firstly you have to create a database (I would recommend Oracle). Then in your GUI you can connect to the database and each button in your GUI will do certain SQL statements that will alter the data in the database.
A good website I found is : http://www.homeandlearn.co.uk/java/java_and_databases.html
Related
I want to synchronize localhost mysql database and online mysql database in java pragramming...
There is this library. https://www.symmetricds.org/ However, I would recommend modifying your design to not need this type of setup. It is error prone at best.. We have used it in the past with moderate results. But you end up with a lot of synchronization errors you have to manually reconcile. It would be much better to code your local application to talk to the remote database directly.
We have an Oracle database which hold data about some cities and
places, etc.
We have a web system which we can manipulate these datas.
We also have a desktop client application which is working with these
data.
For increasing our desktop application performance and decreasing unuseful request for our DAO layer, we have implemented some Singleton classes in our desktop application to fetch mentioned cities, places, etc data only once right after the user is opened his/her desktop application.
Recently we received a request from our clients why we don't see the changes we make using the web application, when the client desktop application is live and up and running. They're complaining about why they have to close the desktop app and open it again in order to see the changes.
We know that the problem is those Singleton classes but we don't want to change them because it's gonna be huge overhead in our system when they're not there. For solving the problem we have thought about multiple solutions:
Create a table in a database with integer column names similar to our data columns (cities, places, etc) and auto increment value when there's an update for tracking the changes using it (a light weight solution)
Using database functionalities
a Notify system that notify the client application whenever an update occurred.
a caching mechanism inside database that cache those lately changing tables and service our users when they have similar request
Here are our stacks:
Our Desktop application is swing application
Our Web application is JSF
Our business layer for both JSF and swing is EJB
Our Dao layer for both JSF and swing is Eclipse-Link
What do you think is the best practice for solving this problem ?
Oracle has a feature called "Database Change Notification" that can be used to be notified when read-mostly tables are changed. It looks like this feature could be a good fit to address your requirement. The link to the doc is here.
In a nutshell, the way it works is that JDBC thin driver in your desktop application would open a port and the Oracle Database would connect to that port and use this connection to push notifications when data changes. You then get a callback through an event/listener API and can refresh your cache.
This notification mechanism is designed for data that is read-mostly, in other words, data that doesn't constantly change otherwise it wouldn't be worth caching the data anyway.
Environment
I have a java application that is going to need access to a mysql database to load and save data and the load/save cannot occur by writing to disk, so it has to be through the database.
I was reading about JNDI but I'm not sure that will help because every example I've seen has been for a java servlet and my goal is to use it in a java standalone application.
Questions
What is the best way to store the mysql username and password so that all clients can access the database but still protecting the login information so that my program is not decompiled and someone uses the mysql login to drop my all my tables?
What would you guys recommend? I'd like this to be secure as possible and I'm open to any suggestions.
Only a handful of statements will be executed on the database and those are hard coded strings that are used in prepared statements so I think that is secure or no?
But my main issue is protecting the database login information.
You have several options:
use credentials with the minimum possible permissions. That means this user will be able to INSERT but not DROP or DELETE
separate the program and the code that writes to the database by creating a webservice (or other remoting techniques)
use only PROCEDUREs and FUNCTIONs to contact the database and grant only them to the user. By doing this you will have a login to the database that is not allowed to do anything except calling procedures and functions.
Complementing the options that #Marged provided you could also encrypt and store the credentials in your code. See encrypt + decrypt examples here Encrypt and decrypt a String in java. This will hide the credentials from any decompiler.
Going with a web service option is a more serious approach and requires a lot more effort and cost to implement and then you need to secure these.
I am brand new to the concept of embedded databases and have chosen HSQLDB to be the embedded DB for my Java app. I think I am fundamentally not understanding something: nowhere do I see how/where to:
Define username/password credentials that must be used for connecting to a database
Creating a new database (e..g, db_myapp)
Creating tables for that new database
With a non-embedded ("normal") DB, I would first use a DB client to connect to the database, and CREATE the db_myapp DB as well as any tables it should have. My app would then expect those tables to exist at runtime.
But with HSQLDB, I have no such DB server to connect to, so I don't see how/where I can create these databases/tables/credentials ahead of time, before my app runs.
And maybe that's exactly what an "embedded" DB does; perhaps its an entire DB embedded inside a JDBC driver? In any event, I still need a way to accomplish the 3 things listed above.
The only thing I can think of is to run some initialization code every time that my app starts up. This code would check for the existence of these constructs, and if they don't exist, then it would create them.
There are several problems here:
This approach might work with databases and tables, but not the credentials I need on the JDBC Connection itself. How/where do I create those?
I'm not even sure if this is the right/normal approach to using an embedded HSQLDB; can someone confirm I'm on track (that is, the "check-to-see-if-it-exists-and-if-not-then-create" approach)?
What happens if I accidentally execute code that tries creating a new database/table eve when it already exists? Will HSQLDB just ignore it or will it blow out my existing DB/tables?
The short answer is that you're pretty much on the right track.
Connecting to the embedded database is really no different from connecting to a normal db server, except that the connection string is a bit different. This section has information on that. The thing is that you don't really have separate 'databases' to choose from, it's just specified in the connection string. For the connection:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:/opt/db/testdb", "SA", "");
This will give you a connection to an embedded database engine that persists the data in the file at /opt/db/testdb. The default username for an embedded database will always be 'SA' with no password. I honestly don't know if it'll work, but if you really need to set a different password, you can try executing ALTER USER SA SET PASSWORD <newPassword>. It'll probably work...
As far as creating tables and such, there's a couple of way of going about this, depending on whether the database will be persisted as a File or in memory. Often times, embedded dbs get used for pretty simple data, and so the tables get created by executing a statement right after initializing the connection. CREATE TABLE IF NOT EXISTS ... is the usual way of doing things. This allows you to create a table only if it doesn't already exist.
If you're working with a file-base database, then hsqldb gives you another option. Take a look at this documentation about accessing a database using their tools. This would allow you to create a file-base database ahead of time, and set things like username/password and setup all your tables. Then you can just copy over the resultant file to be used by your application. Then everything would be setup before your application connects to it.
So ultimately, you have the option to go either way. You can either have your application set everything up when the connection is initialized, or you can set it up manually ahead of time. My preference is to have the application set it up in code simply because then your table definitions are kept closer to the code that actually uses them. I haven't used an embedded database like that for really complex data, though, so I can't honestly say how well that scales.
Since I'm not really proficient with databases, some details may be irrlevant, but I'll include everything:
As part of a project in my University, we're creating a website that uses JSP, servlets and uses a MySQL server as backend.
I'm in charge of setting up the tables on the DB, and creating the Java classes to interact with it. However, we can only connect to the MySQL server from inside the University, while we all (7 people) work mostly at home.
I'm creating an interface QueryHandler which has a method that takes a string (representing a query) and returns ResultSet. My question is this: How do I create a class that implements this interface which will simulate a database and allow others to use different DBHandlers and not know the difference and allow me to test different queries without connecting to the actual MySQL database?
EDIT: I'm not so sure on the differences between SQL databases, but obviously all the queries I run on MySQL should run on the mock.
Why not just install your own MySQL database for testing? It runs on Windows, Mac and Linux, and it's not too resource heavy. I have it installed on my laptop for local testing.
Your API appears to be flawed. You should not be returning ResultSets to clients. By doing so, you are forever forcing your clients to rely on a relational database backend. Your data access layer needs to hide all of the details of how your data is actually structured and stored.
Instead of returning a ResultSet, consider returning a List or allowing the client to supply a Stream that your data access component can write to.
This will make unit tests trivial for the clients of the API and will allow you to swap storage mechanisms at will.
Try derby. It's a free server you can use to test against, if you don't mind having to change drivers when you go back to SqlServer. You might be limited in the kind of queries you can run though. I'm not sure if SqlServer has any special syntax outside of standard SQL.
How about using a HSQLDB for offline tests? It wont behave exactly like a MySQL DB but is a fast in memory SQL DB that should satisfy most of your needs.
The best way in my experience is multiple database instances and or schemas. Normally you'd have one for each user to do their development against/sanity checking the running application, one for an automated build for running unit tests and ideally one for each user to run their unit tests against. And of course instances/schemas for demos, integration testing. Apart from the practial side, being able to do this ensures deploying/upgrading the app/database will be pretty near faultless too.
Assuming you have a DAO layer, the only code that needs access to a real database at the unit test level is the DAO implementation, the business layer should be using a mock DAO implementation.