Im trying to write an article on how databases in modern day smart phones(Android,Symbian,iOS,BlackBerry) operate, however couldn't find any material on the internet, despite searching quite a bit. Any pointers in the form of links or input would be appreciated.
they all use SQLite.
Simply put, it's a serverless SQL database. Or in other words, a C library that takes SQL commands and returns results as read from (or written on) the data stored in a single file.
It's really compact code and works great when you don't need heavy concurrency.
Related
I'll begin with explaining how I stumbled upon SQLite Asset Helper library. I am trying to build a small android application which is basically shows the meaning of words. And to do so I intend to keep everything offline (no dependence of internet connectivity). Now, as far as I can think of, there are 2 ways of achieving that:
1. Using String array, which I believe will be a tedious task and a memory hog.
2. By providing a pre-populated database, using which I can easily establish relations between words and their meanings and do more (searching, sorting, etc).
Now, the problem I am facing is supplying a pre-populated database (or words and meanings) with the app itself. And for doing that I came across SQLite Asset Helper which does the job.
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android. Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)? Is it acceptable method? Any other better alternative up for suggestion would be great!
I have read a number of articles related to SQlite Asset Helper but not many which confirm its implementation on latest iterations of Android
It works on the latest iterations of Android.
Also, is the only possible solution to deliver a pre-populated database to the user (without needing to go online)?
You are welcome to roll your own implementation. I do not know what you would gain by this.
Is it acceptable method?
I am not aware of anything better.
I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.
I have three tables with 5 columns each. They can grow upto 15 rows each.
Does it make sense to have a SQLite database for this or should a file suffice? I am talking about pure performance basis.
my suggestion is to go for Sqlite, Sqlite having cursor which can navigate data, modify data very easily.
The same thing with File is quite complex, for that you have to do string function like indexOf(), subString(), replace() etc.
From a performance point of view this will matter very little, but from a maintenance point of view you should go with the sql approach, stay clear of any arcane home-brew approaches if there is a general well-known way of doing something :)
Also it should be a lot faster to write the code for the database rather that for the flat file. And, never optimize until you can measure and see that you have a performance issue.
Do you need any sort of concurrency support? If so, SQLite would make sense, rather than building that yourself.
I would side with using a database, since it would likely be easier to maintain the integrity of your data, with respect to relationships and the format of the data you're storing. Making an error when updating a table is easy to notice (exceptions are nice to prevent corrupt data), but writing out malformed data to your own format might not be easy to spot until it's too late.
Performance should probably come second to maintaining valid data.
I would also clearly vote for the DB solution. Additionally to the mentioned advantages, it's a good thing to learn anyway - and - honestly - at the end considering all issues it's not harder or more work than the file system solution.
By the way, back then I learned the DB with this tutorial: http://developer.android.com/resources/tutorials/notepad/index.html
It was alos very usefull for couple of other reasons...
If you don't already have a MySQL database and don't need any tricky joins, go with the filesystem.
I do web, not android, but I've had great success consuming JSON manifests out of the filesystem using JavaScript. It's so nice to cut the database overhead, and the filesystem is practically instant.
This is my first time trying to work with a database, so bear with me.
I need to write a program that will use a database that I do not have access to yet. I know there is MySQL, SQLite, and a bunch of other SQL things, but I'm not sure what the difference between them is. Do I need to know what kind of database it is before I can use it (i.e., is a MySQL .db file different from a SQLite .db file?), or is the file itself going to be the same and the difference is how it is accessed?
EDIT: I am programming for an Android tablet, that probably matters. But I will not be creating the database, it will be given to me and I have to work with it.
You might want to run through a view tutorials creating a MySQL database, and a SQLite instance to see how they work and how you can easily interact with them.
The access to each involves adapters, notwithstanding creating the tables you'll need, the user access (username / password / role to access the table).
Here's a straight-forward sqlite tutorial:
http://zetcode.com/db/sqlite/
https://zetcode.com/php/mysqli/
http://zetcode.com/php/pdo/
Here's a staight-forward sql with C# tutorial:
https://zetcode.com/csharp/mysql/
I remember being overwhelmed with databases my first time. My advice is to start with something well-supported, with a nice community, and search results a-plenty of tutorials, where you can grasp the fundamentals.
Then, based on your application requirements, and platform constraints, you can determine where to pivot. But reviewing the differences between databases without actually having worked with them is like trying pieces of sushi without ever eating fish.
EDIT:
If you're building on Android, yep, learn SQLite.
I highly recommend this tutorial to help you see SQLite used in an Android project:
https://developer.android.com/training/data-storage/sqlite
For data abstraction / ORM, you should familiarize yourself with Content Providers and Cursors (http://developer.android.com/guide/topics/providers/content-providers.html)
Good Querying!
First off, you'll need to know what type of database it is before you can connect to it as you'll need to use the appropriate database driver for your platform. mySQL, Oracle, Postgres, SQL Server, etc will all use different drivers as the binary protocol used to talk to them (authenticate and transfer information back and forth) is different.
As far as your actual SQL code, it depends. For the most part, you can count on SELECT * FROM Foo working with any SQL compliant database on the planet. However, once you start doing anything more complicated or using non-standard keywords, you might run into trouble. For example, some databases support the USING keyword for JOINs and some don't.
One thing you might look into is an ORM. This will allow you to abstract the actual SQL dialect from your program and then (for the most part) not have to worry about the actual SQL. Some popular ORMs are ActiveRecord (for Ruby on Rails) and Entity Framework for .NET. Hope this helps!
UPDATE:
Since the Android tag was just added to the post, I did a quick search for SqlLite ORMs that support Android and came up with this. Maybe worth checking into, or perhaps someone can comment on whether it's any good :)
Database Abstraction Layer is the strategy of having a smart middleman so you can program without knowing exactly which database system you have underneath. Database Abstraction isn't as utopian in practice as it sounds, and most people end up programming directly for a particular database. You will likely find that the more experience you get with your database of choice, the more you wish you knew its particular nuances better. So the short answer is there is enough difference to matter!
If you use a software architectural pattern like Model-View-Controller, it can enable you to do a lot of your programming irrespective of the database you use. Taking Model-View-Controller as an example, you could program your Controllers and your Views without knowing what database you are using.
The limitation to what you can do before deciding on a database system is the inconvenient fact that good programming practice calls for fat Models and skinny Controllers. So a big part of your actual programming effort is held hostage by your choice of a database solution.
If I didn't know what database would be used, I would start programming my View and then my Controller. If PHP is your language, you may find a CodeIgniter tutorial enlightening.
An article about "Appropriate Uses For SQLite"
http://www.sqlite.org/whentouse.html
Summary：Checklist For Choosing The Right Database Engine
Is the data separated from the application by a network? → choose client/server
Many concurrent writers? → choose client/server
Big data? → choose client/server
Otherwise → choose SQLite!
I want to store structure type data (i.e. information of call logs like name, number, type of number, date, time, duration). Which is the best way and which is faster? SQLiteDatabase (make table and insert, delete logs in it) or use file storage (means make one class for all parameters and write their objects in file using input/output Stream and serializable) or the another way i heard about it is XML parser but i don't know this.
Please help me. Thanks in advance.
It depends on what you are trying to do.
If your goal is speed, the SQLite will give you a serious run for your money (especially if you wrap multiple inserts into transactions). SQLite has been optimized for everything you mentioned and it would be very easy to leverage the speed it can give you.
If portability is your goal, then files may be a slight bit easier. Files can be moved back and forth very easily easily, whereas SQLite might take some more effort.
If being able to search is your goal, then you'd be a fool not to use SQLite, as it is extremely good at searching and filtering results.
I can't give a very informed answer here because I'm just as new to the subject as you are, but here is the link from the developers page that goes over the different types of data storage. I hope you find it useful. http://developer.android.com/guide/topics/data/data-storage.html
Personally, given you know the basics of Databases I would use a sqlite database. It's pretty straight forward in Android. In terms of speed I don't know which is faster, but if you don't have millions of datasets it won't matter.
In my experience in most cases JSON in a file is enough (mostly you need to store an array or an object or just a single number or string). I rarely need SQLite (which needs more time for setting it up and using it).