So I'm following a tutorial on how to create a simple Android app that stores a bunch of random quotes. I've noticed that they used a SQLite database and many other Android tutorials uses SQLite to store things. I'm not very used to SQLite. Can I achieve the same result just by storing the quotes in a hashtable?
What are the differences between a SQLite database and a hashtable in terms of performance?
What are the differences between a SQLite database and a hashtable in terms of performance?
An (in-memory) hash table is (you probably should use HashMap) is going to be faster. However, it does not address the problem of making your quotes "persist" when your app has shut down.
SQLite is a database, and the main point of a database is that the data persists.
(There are a whole bunch of other benefits in using a database of some kind. One that is potentially relevant to you is that you can store more stuff in a typical database than you can hold in memory. The database stores stuff on your device's hard drive / SSD / whatever which has far more capacity than main memory.)
http://www.brighthub.com/mobile/google-android/articles/25023.aspx
I suggest SQLite because u can access the database very easily and it is easy to understand and view the database tables also very easy through DDMS plugin for eclipse The above link helps you in DDMS
It's up to your intention. If you want to store data such as app preference, user score.. use SQLite. These data will be available for the next launch of application. Hashtable is in memory, of course it is faster than SQLite, all information stored in Hashtable will be lost when the app is deactived or terminated.
Related
I am fairly new to programming java and I just started working with SQLite databases. A school assignment is requiring me to create a stand alone GUI program that can store data. After some research, I will be using a SQLite manager downloaded from Firefox. After completing my project, will it still able to run stand alone? Or will the SQLite manager be required to input data. Thank you
Yes, if you include the respective SQLite libraries. In fact there is little need for the SQLite Manager although the resultant file could be copied and used.
In short the SQLite database is a file that you open (connect to) using the respective library functions/API. Noting that some functionality may depend upon the version of SQLite (which could well be lower on the SQLite Manager).
You could also manage without the SQLite Manager, creating the database and tables therein within the program. Generally you'd use a SQLite Manager to provide a pre-populated database (noting that if using a pre-populated database that identifiers (table and column names) should match (case doesn't matter)).
I am currently developing a program in Java using NetBeans that manages expenses. In this program I used MySQL to store data. Now I want to ask that if I give the program to one of my friend, he would also have to install MySQL using the same password that I used. Is there a way in which he will not be required to install MySQL?
Now suppose if my friend already has MySQL, but with a different password. My program would not work in that case, and it would be hard to replace my password with his password in the code. Is there a way to make the program run on his PC?
Earlier once, I have used an Oxford dictionary program. That time I did not have Microsoft Access installed. When I installed Microsoft Access I came to know that all the words of the dictionary are stored in a Microsoft Access file. How can I do this? I.e. how can I use MySQL/Microsoft Access to store data without the need to install either of them?
You can use an in-memory database like H2 Database if you don't require a large amount of data
But I think you should make your db connection configurable by using a properties file
If you want everyone to be able to use the database, you need to run it on a server that people can access through the internet.
However if you don't care about them using the same database and just want them to use their own, you could for example create a small file named "config.ini" or something like that and put the login information (like the password) in there.
Then just read it in your code and use the info you read to log into your database.
That way, every new user will only have to change the config.ini file without ever having to touch the code.
The best solution in my opinion would be SQLite as it is light, and data can be stored locally in a desired location in a single file. H2 is more likely to be a developer tool.
This solution does not require additional software to be present on the user machine. Of course it has its limits, but as a simply storage for program dynamic data it is a good solution. It is worth mentioning that Android applications also can store their data in LiteSQL. It is a bit different approach there, but the principle stays the same.
There seems to be a 1MB limit on Android's Cursor Window size which limits the ability to read BLOBs from SQLite. I know you may say we should not store BLOBs in database but by definition, BLOB is considered a Binary Large Object and if there was no need to store them in database, there was no need to implement such object type in any database engines.
The 1 MB limit on the implementation of Cursor however, seems to be insufficient in almost all cases. I need to store my binary data for valid reasons in SQLite database and they are well over 1 MB. SQLite is capable of handling BLOBs perfectly since the C API is working perfectly fine in Xcode (iPhone platform) to retrieve large objects without any issues.
I'm wondering if we can possibly access the BLOB data in Android without using cursors. I am thinking of a lower level access to Sqlite in Java. Any suggestions?
As CL mentioned, using NDK is indeed a way to access Sqlite natively via C language in Java language. However I realized it could get really messy if I wanted to write a custom wrapper myself and try to access the functions in Java.
After searching around, I came across a brilliant open source project called Sqlite4java which is a tight wrapper around Sqlite, compiled to use on various platforms including Android. This library allows you to interact with Sqlite without using Android Cursor which removes the limitations.
I am able to retrieve 20 MB of Blob in 480 milliseconds. This is even faster than reading a small record from Sqlite via Cursors. I believe this can be used to enhance any query to Sqlite by skipping the use of Cursor. Here's the link to this great library: http://code.google.com/p/sqlite4java/
Android's Java API always has the 1 MB limit.
You should not store BLOBs of that size in the database; the file system is more efficient at handling them.
If you really want to use BLOBs, you have to go through the NDK to access the C API directly.
I am collecting data from a website and trying to save it to a database (or something similar that is very accessible) rather than having a heap of files on my desktop or in a folder.
There are many pages that I need to look at (1900 to be exact). I want to save time in getting this data, and decided to make a Java program to do this.
This is basically what I am trying to do.
Visit the webpage: www.TestWebsite.com/items/0
Save the (Name, Description, Image(png)) into one array/class to a Database.
Repeat until I get up to: www.TestWebsite.com/items/1899
I want to be able to access this data offline without having to need to go online to view it.
Any ideas on how I should start. I have made a basic webpage viewer, I am just missing the step in between saving the strings and images to a database.
I appreciate any help!
Actually just did this the other day. I used jsoup to scrap the webpages I needed and wrote to my local database. awesomely easy framework for webpage parsing.
It's fairly straightforward, but you'll need to learn a little SQL if you haven't already.
You'll also have to pick a database platform - I'd suggest SQLite for such a purpose, since the data is for personal use and it's lightweight and easy to set up.
Here's a tutorial on using JDBC (Java Database Connectivity) to talk with a SQLite database: http://en.wikibooks.org/wiki/Java_JDBC_using_SQLite. It goes from setup to inserting data, so once you've completed that it should be straightforward to modify your webpage viewing code to grab the data you need and shove it into the DB.
Good luck!
I have this requirement for my business. We have a swing desktop application that works with a mysql database. At the end of each day the swing app exports the data that has changed and uploads it to a server. The set up is, a user working in an office, will have many companies that he is working with. If he changes any data for that company, then I export that company's data alone from the database. The data is exported in the form of java objects, serialised and stored into a file which gets uploaded.
The next day, if there are any changes made to that company again then I will replace the file in the server with the latest uploaded file.
Now on my server, I would like to work with this file. I would like to convert each of these files into mini databases that a webapp can read. It will not write to it. Everytime the user uploads, the database will be deleted and recreated.
So ultimately each of these files are a small subset of the data that a user has in his desktop application.
Now this issues are:
The objects that I have exported are "Apache Torque" objects. Torque is an ORM tool, basically the object represents the table. I need to convert this object into a database. Sqlite, HSQLDB, Derby...? The database should be small. If the object file is about 5KB, then the database that represents that file shouldnt be 3MB. Derby did that actually.
The java object classes could change. Since the underlying database could change. Hence I will need to deserialise these objects and create a database from it as soon as it is uploaded. Otherwise, I will not be able to deserialise these objects later on. Small changes to the database is fine for the web application. But if I dont deserialise it immediately, then I am stuck.
The conversion from the java object to the database should be fast. Since the user actually waits when his data is getting uploaded I would like to add a maximum of 5-10s additional for the conversion.
Is it ok to have thousands of these mini databases lying around? Is this design okay? Is there an alternate solution?
I wouldn't try to put each dataset into its own database. I would put all of them in one big database, along with a column in the key tables indicating the dataset that each row applies to (this sounds like it should just be a company identifier). This is a more normalised design than having many small databases.
You will then need to write the webapp so it makes queries for particular datasets, rather than connecting to a particular database.
if you adopt that approach, you can deserialize and store the datasets as soon as they arrive. The storage is simply inserting rows into an existing database, so it should be very fast.
In addition, i expect that one big database will be much easier to manage, maintain, report on, etc, than many small databases.
If you tell us more about the details of your schema, we could discuss how the database could be organised, if that would be useful.