As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm developing a Java application that communicates with a MySQL database in a server. The app should be able to read some data from an XML file and then insert the info read into the database.
I used to write SQL Statements directly to the Java code, but then a friend advised me to create a web service that does all the SQL stuff for the tool, and let the tool's only job is to read XML and send data into the web service.
My question is, does it deserve that effort? Why or Why not?
SQL in code is not recommended as it becomes difficult to maintain. The application is also tightly coupled to the database structure. Every time the database change (or you are moving to a new database) you need to make changes to your code and release again.
I don't think a web service is the correct answer here. I would recommend you try one of the following:
If your application uses a lot of tables and very high throughput is not critical, use Hibernate as an ORM tool. It has many features and can really reduce the time spent on data access.
If you do not have that many tables and you don't have the time to learn Hibernate, use iBatis. It will take you 30 minutes to grasp. It essentially allows you to put your SQL in a separate XML file, which it will read for you. For smaller applications it is really useful and it is faster than Hibernate.
As a last resort, rather put your SQL in a text file(s) which you open and execute.
How do you intend to create the webservice part? If you have the time to do, worth trying with Core Java or any Webservice framework, though I would suggest use Core java which would help to keep minimal dependency for your tool. Nevertheless, there is an ample amount of effort required to get the XML and Webservice requests in sync. My take - if it is not broken, dont fix it.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is my first question on StackOverflow. I'm new to it all. I know you're all pretty strict here, so I did all the research I could before asking this. Unfortunately I came up empty.
I'm building an app that shows an event that occurs every three months. This event has different shows in it that change very often. That is where my app comes in, it keeps people updated on what will be happening at the event. So when the event planners change their schedule, I need it to update my users. Pictures need to be changed too. Obviously, having them update the app is not the easiest way.
I know I could build a webpage, and have the app read off that. But I am really hoping there is an easier way than that. And if the webpage IS the only way, what is the best api?
So my question is; What is the easiest way to do this, so I can do more research about it?
https://www.parse.com/
Parse might be your best option if all you need is some basic data on a server. You don't need to write a whole web application or scrape html off of a web page. If you need other non technical users to write this data, you can make one "manager" version of your app and include some authentication logic (which you could also do against your Parse account). I have done this kind of thing using Amazon S3 buckets when I didn't have the time to write a whole web app just for some very basic server interaction for a mobile app.
You're going to want to have a server that your app can talk to. I would do this in two parts that have to happen more or less at the same pace. First, I would use Google's Cloud Messaging API to do the "light lifting" - it lets your app do a small check to see if anything needs updating. Then I would set up the server. You're obviously going to need to learn how to open up connections, downloads, storage, etc.
Important thing to keep in mind though, efficiency. Be smart about the data transimitted. Keeping it simple will benefit your app (less code, more straightforward) and your users (smaller app, less data usage).
But first, do research, try stuff out and don't be afraid to ask questions.
you don't need to build a webpage, you just need a server that the app can query
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was thinking that doing java code for executing DDL, DML etc is cumbersome and involves a lot of typing. So, I was thinking if databases have/can be made to have the following feature -Take a script in a text file and execute the entire script.
If we had something like this, then we could type our SQL queries into a text file in the usual, easy way. The java code then sends this text file to the DB which executes it as if someone had typed the script into its management GUI.
Is this possible ? What could be the disadvantages of such a system ?
Pretty much every database I am aware of has such a capability (including MySQL mentioned in your tag). You simply do something like this from a command line client (this example for MySQL)
mysql -h hostname -u user < sql_script.sql
There is no middle layer of using some programming language to pass the file.
I would say go for it for your DDL. I always drop my table/index/constraint creations in a SQL script and run it to setup my database.
However, for DML, like other posters have said, you will be doing these queries often (usually) based off of user input. If the user creates some object in your system, you will end up saving it with one or more inserts/updates. The parameters to those statements will be the values the user entered into your system. It will be more maintainable and easier to understand if you use Java's facilities for executing these directly. Trying to replace tokens in a SQL file with the parameters and passing it to the database would quickly become more cumbersome.
What you suggest is essentially something like evoking Stored Procedures on the RDBMS.
The disadvtantage being that your domain-logic now resides in your persistence-layer which is (can be) bad for several reasons.
One of the main problems being: code maintenance: programmer nightmare from maintenance standpoint as well as programmers requiring skill in both domani logic as well as sql-statements. Depending on the size of your team, this may be a big concern. Generally adhere to the rule Separation of Concerns
You need statements in Java code because most of the values sent as parameters are only known at runtime: they come from the GUI, and from all the business code executed between each query. Otherwise, yes, what you want exists: they're called stored procedures.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a system that the backend currently relies on Python.
Basically it has a series of scripts that will go through a MySQL database and check for certain parameters across multiple tables and then perform actions such as send emails and text messages then amend relevant cells to say these issues were dealt with. There is then another script that sits and listens on a port for UDP packets, unpacks them validates them and if they pass validation inserts them into the database and check to see if the data triggers any alarms will send an email and tech message.
My question is am I doing this the most efficient way? As I am not sure how to have a system of checking to see if the scripts are running and if not relaunch them. All of them run infinitely 24/7. Would rewriting them in Java be more stable and efficient?
There is no real way to answer either question without knowing all aspects of the system.
If your system basically have 2 scripts written in Python that perform well I don't see any reason whatsoever to change that architecture. One more consideration that I would give you to ponder is that at least one of these scripts is a support script and the guys responsible for support mostly don't care much about Java to be able to troubleshoot the code.
As far as JAVA is concerned I am not sure that you would be better off with Java then you are with Python. There is no shortage of expertise out there in either language but given what the programs are used for I'd say Python would be a better choice. If you are concerned about performance though I would look at Cython as a possiblity.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm relatively new to Java and using DBs with it, and I need help deciding which embedded RDBMS to use with a simple J2SE system. My criteria and concerns are: performance, low system requirements, reliability, easy of use/develop/deploy/maintain/backup/recovery.
1) Before I was deciding between Firebird and SQLite, but then I've just met H2, HSQLDB and Apache Derby, and now I don't know which one to choose. Any of them would fit for me, but I need to explain why I choose one of them.
I believe I should use one of the native Java ones, since they can run inside the same JVM (which might use less resources). Which one do you suggest and why?
2) I also would like help on finding backup/recovery/maintenance manuals, tools and commands for H2, HSQLDB and Apache Derby, since I was not able to find this information on their website (not because the documentation is bad, most likely I'm a bad seeker)
P.S: this might be a good source for others with the same problem, but be careful because the information is not fully up to date: http://database-management-systems.findthebest.com/compare/6-13-15-16-53/Apache-Derby-vs-Firebird-vs-HSQLDB-vs-H2-vs-SQLite
H2 was written fairly specifically to be faster than HSQL and Derby. Its author has run some benchmarks which, although they are rather old now, indicate that this goal was attained. According to those benchmarks, H2 is a bit faster than HSQL, and H2 and HSQL are much faster than Derby.
I don't know anything about management tools for any of these databases. Since they're embedded, they store their data in local files; it should therefore be easy to handle backup and restore by backing up and restoring their files.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I develop 3 to 4 Spring Roo applications a year currently with Hibernate and MySQL. It has been stated here at Stackoverflow that relational databases are not the best fit for a typical object oriented webapplication .
If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.
There are various reasons for this. One is productivity as objects are mapped to a relational schema ("joins" etc.). Would the use of MongoDB or CouchDB increase development productivity given the same level of expertise as with MySQL?
I think it really depends on the web application. Non-relational databases (NoSQL) excel where you either
Don't want a schema (want to be able to store different sorts of data in the same table), and/or
Don't have too complex of relation between objects.
NoSQL can definitely make it easier to get off the ground faster, because you can just throw stuff in however you want, but on the downside as things get more complex sometimes you want a little more forced organization. Foreign keys are something I really miss when working with Mongo, just being able to (using an ORM) hop from one object to a related one or set of them is great. (Yes in many NoSQL dbs you can store documents, but at some point you need to use a separate table for something.)
I would highly recommend NoSQL for a brochure style website, where the client is just entering text fields, or a twitter-style site, where largely you are storing lots of one type of data with few attributes. But if you're going to be creating a CMS with revisions and workflow and such, you're going to want the ability to have explicit relations in SQL.
Which brings me to my answer: use the right tool for the job. A trained developer would be able to make some sites faster and better with SQL, and other sites faster and better with a non-relational database.
But try out MongoDB or CouchDB and get a feel for it, that way you'll have a better intuition on when to use what. (We use both at my job (not at the same time!) depending on the project)