I am currently working on a project that was not made by me but it makes use of a lot XML files instead of MySQL in place of it.
Because of that it makes me wonder if there is really any benefits of using XML over MySQL here.
The scene is, the XML files are loaded only ONCE and used on the server for N things it does.
The XML is only reload if the admin issue a command to the server to reload it.
All the XML files together have an average of maximum 100 mb size.
If you could as well give me a little brief of the above in regards the usage of XML over MySQL would appreciate.
What should I consider to know when a XML would be a better option over a simple innodb or myisam table ?
If your data is read-only and brought into memory only at the command of the admin, then I don't think it's much of an advantage for either technology.
MySQL would have the advantage of SQL queries if you have to search the data. Even in that case it's the type of data that matters. If you have long reference chains/object graphs, then a relational database may be slow because of all the JOINs.
But XML has its own issues. You can easily parse it into a DOM object, but then you only have XPath to search it.
XML is used as one of the ways of storing data. one of using xml is, it makes the data easy to be readable. you can use mysql if there are lot of users need the access to the data at the same time and mysql also supports transactional processing of data whereas xml does not have such features.
just adding the option in between - you could also use some form of xml database like
eXist (http://exist-db.org/index.html) or sedna (http://modis.ispras.ru/sedna/)
XML stored at local storage, and readable only by local server (don't argue me you can use memcache, replicated via rsync or so)
No doubt you can open the XML via a http server, but it will be slow.
While, mysql support port communication, and replication, it basically don't have boundaries if you expanding to multiple servers.
And even at 5.1, mysql support XML
Related
I want to develop a desktop application that allows users to search through json files.
These files (around 50.000) are predefined. They should be shipped with the application itself.
My question is, what would be the best way to ship these documents with the application and at the same time allow users to search for documents containing certain values, e.g. in sql terms: show all documents where some json value within the document like %Example%.
I thought about using some kind of NoSQL solution, preloading the files into the db and bundle it with the app. I've looked at some solutions, but I'm not really sure which one would be best suited for my needs or if it's even the best approach.
Bottom line is, I can't have my users install a db on their system, that is way too complicated.
I'd prefer a solution suitable for java or python.
Thanks for your help!
You can use an embedded database, memory based database (like hsql) or a file-based database like sqlite.
Neither require any installation from your end users. You just have to package the libraries as part of your application install bundle (and of course, the engine itself).
If you are looking for a k/v store, then the good ol' Berkeley DB should suffice. If you are really looking for a "embedded NoSQL solution", try MooDB.
Mongo DB comes in an embeddable version: https://github.com/flapdoodle-oss/embedmongo.flapdoodle.de
I've used it for integration testing (mocking a Mongo server) and it works really well!
Anytime I read document and search, I also think of Solr: http://lucene.apache.org/solr/
Is it possible to use the SQLXMLBulkload component of SQL Server using Java? I am using SQL Server 2005 database for my Java EE application.
If not then is there any similar API for Java?
Ultimately I found out that there is no nice way of doing it. Persisting XML to Relation database is still a challenge.
For my project I end up marshaling XML to Java and then persisted Java objects to DB with the help of Hiberante:
I understand that performance is a big concern with this approach but I didn't hit any performance issue yet. Plus this approach give me flexibility for example saving attribute values in separate columns etc.
I'd like to save persistent objects to the file system using Hibernate without the need for a SQL database.
Is this possible?
Hibernate works on top of JDBC, so all you need is a JDBC driver and a matching Hibernate dialect.
However, JDBC is basically an abstraction of SQL, so whatever you use is going to look, walk and quack like an SQL database - you might as well use one and spare yourself a lot of headaches. Besides, any such solution is going to be comparable in size and complexity to lighweight Java DBs like Derby.
Of course if you don't insist absolutely on using Hibernate, there are many other options.
It appears that it might technically be possible if you use a JDBC plaintext driver; however I haven't seen any opensource ones which provide write access; the one I found on sourceforge is read-only.
You already have an entity model, I suppose you do not want to lose this nor the relationships contained within it. An entity model is directed to be translated to a relational database.
Hibernate and any other JPA provider (EclipseLink) translate this entity model to SQL. They use a JDBC driver to provide a connection to an SQL database. This, you need to keep as well.
The correct question to ask is: does anybody know an embedded Java SQL database, one that you can start from within Java? There are plenty of those, mentioned in this topic:
HyperSQL: stores the result in an SQL clear-text file, readily imported into any other database
H2: uses binary files, low JAR file size
Derby: uses binary files
Ashpool: stores data in an XML-structured file
I have used HyperSQL on one project for small data, and Apache Derby for a project with huge databases (2Gb and more). Apache Derby performs better on these huge databases.
I don't know exactaly your need, but maybe it's one of below:
1 - If your need is just run away from SQL, you can use a NoSQL database.
Hibernate suports it through Hibernate OGM ( http://www.hibernate.org/subprojects/ogm ).
There are some DBs like Cassandra, MongoDB, CouchDB, Hadoop... You have some suggestions Here
.
2 - Now, if you want not to use a database server (with a service process running always), you can use Apache Derby. It's a DB just like any other SQL, but no need of a server. It uses a singular file to keep data. You can easily transport all database with your program.
Take a look: http://db.apache.org/derby/
3 - If you really want some text plain file, you can do like Michael Borgwardt said. But I don't know if Hibernate would be a good idea in this case.
Both H2 and HyperSQL support embedded mode (running inside your JVM instead of in a separate server) and saving to local file(s); these are still SQL databases, but with Hibernate there's not many other options.
Well, since the question is still opened and the OP said he's opened to new approaches/suggestions, here's mine (a little late but ok).
Do you know Prevayler? It's a Java Prevalence implementation which keep all of your business objects in RAM and mantain Snapshots/Changelogs in the File System, this way it's extremely fast and reliable, since if there's any crash, it'll restore it's last state and reapply every change to it.
Also, it's really easy to setup and run in your app.
Ofcourse this is possible, You can simply use file io features of Java, following steps are required:-
Create a File Object
2.Create an object of FileInputStream (though there are ways which use other Classes)
Wrap this object in a Buffer object or simply inside a java.util.Scanner.
use specific write functions of the object created in previous step.
Note that your object must implement Serializable interface. See following link,
I'm currently working on a simple Java application that calculates and graphs the different types of profit for a company. A company can have many branches, and each branch can have many years, and each year can have up to 12 months.
The hierarchy looks as follows:
-company
+branch
-branch
+year
-year
+month
-month
My intention was to have the data storage as simple as possible for the user. The structure I had in mind was an XML file that stored everything to do with a single company. Either as a single XML file or have multiple XML files that are linked together with unique IDs.
Both of these options would also allow the user to easily transport the data, as apposed to using a database.
The problem with a database that is stopping me right now, is that the user would have to setup a database by him/herself which would be very difficult for them if they aren't the technical type.
What do you think I should go for XML file, database, or something else?
It will be more complicated to use XML, XML is more of an interchange format, not a substitute for a DB.
You can use an embeddedable database such as H2 or Apache Derby / JavaDB, in this case the user won't have to set up a database. The data will be stored only locally though, so if this is ok for your application, you can consider it.
I would defintely go for the DB:
you have relational data, a thing DBs are very good at
you can query your data in that relational much easier than in XML
the CRUD operations (create, read, update, delete) are much more easier in DB than in XML
You can avoid the need for the user to install a DB engine by embedding SQLite with your app for example.
If it's a single-user application and the amount of data is unlikely to exceed a couple of megabytes, then using an XML file for the persistent storage might well make sense in that it reduces the complexity of the package and its installation process. But you're limiting the scalability: is that wise?
I am using Hibernate in a Java application to access my Database and it works pretty well with MS-SQL and MySQL. But some of the data I have to show on some forms has to come from Text files, and by Text files I mean Human-Readable files, they can be CSV, Tab-Delimited, or even a key, value pair, per line since my data is as simple as this, but my preference of course is XML files.
My question is: Can I use hibernate to read those files using HQL, Query , EntityManager and all those resources Hibernate provides me to access files. Which file format should I use and How I configure My persistence.xml file to recognize files as Tables?
Hibernate is written against the JDBC API. So, you need a JDBC driver that works with the file format you are interested in. Obviously, even for read-only access, this isn't going to perform well, but it might still be useful if that's not a high priority. On a Windows system, you can set up ODBC datasources for delimited text files, Excel files, etc. Then you can set up the JdbcOdbcDriver in your Java application to use this data source.
For most of the applications I work on, I would not consider this approach; I would use an import/export mechanism to convert from a real database (even if it's an in-process database like Berkeley DB or Derby) to the text files. Yes, it's an extra step, but it could be automated, and the performance isn't likely to be much worse than trying to use the text files directly (it will likely be much better, overall), and it will be more robust and easy to develop.
A quick google came up with
JDBC driver for csv files
JDBC driver for XML files
Hope this might provide some inspiration?
Like erickson said, your only hope is in finding a JDBC driver for that task. There is maybe xlsql (CSV, XML and Excel driver) which could fit the task. After that, you just have to either find or write the most simple Hibernate Dialect which fits your driver.