I was reading this article (http://www.vogella.com/tutorials/AndroidSQLite/article.html) to learn about SQLite databases in android apps.
In the article he has a tip:
It is good practice to create a separate class per table. This class defines static onCreate() and onUpgrade() methods. These methods are called in the corresponding methods of SQLiteOpenHelper. This way your implementation of SQLiteOpenHelper stays readable, even if you have several tables.
if I understand this tip correctly I should have a class for each table that I have in my database?
Is that really the best practice?
If so, what about complex queries that uses multiple tables? how do I manage that if the creation is in different classes?
How do I correctly keep the database version? for each table change I will change the database version number?
Thanks
SQLiteOpenHelper manages database files, not tables. You manage the tables yourself with the given database lifecycle callbacks (onCreate(), onUpgrade()).
Quickly reading one could interpret that the author advocates creating a separate database helper for each table (I did at first), but that's not the case. That would have been bad advice.
To reiterate the author's intent:
One database helper class.
The helper involves separate table-specific helper classes which are not SQLiteOpenHelpers but just doing part of the work for the top-level database helper.
Related
I have huge DB, written with SQLiteOpenHelper. Now we are starting to implement Room to our project. So, my question is: how to be with migration problem?
For example, I have version number 100 in MySQLiteOpenHelper. I'm trying to migrate one table (and there are many other tables in DB) to Room.
I've create MIGRATION_100_101 in
MyDatabase : RoomDatabase (#Database(version = 101) class. So, I need to increase version in MySQLiteOpenHelper to 101 and make sure, that MyDatabase with migrations will be called before MySQLiteOpenHelper?
Is there any other way to have both SQLiteOpenHelper and RoomDatabase in one app?
AFAIK Room manages a separate database by itself and there isn't a great way to maintain a custom sqliteopenhelper and a room database. What we did was that we migrated subsets of the tables at once from old sqlite to room (basically, tables that need to be joined together for whatever reason), and kept two separate databases until all of the tables were migrated.
Depending on your situation, might be more painless to do a one-time migration for everything.
The only solution, that allows us to do this is next. Let's imagine, that current DB version is X and we are planing to migrate to version X+1.
Create SQLiteOpenHelper object that will drop all tables, if the current DB version is X and recreates all NOT migrated tables for version X+1. We need to call getReadableDatabase/getWritableDatabase method so, table creation (methods onCreate/onUpgrade) takes place. This SQLiteOpenHelper object will be temporary.
Create RoomDatabase object for version X+2 with fallbackToDestructiveMigration. This will clear all migrated tables and recreates them. Also, we need to call getReadableDatabase/getWritableDatabase for creation take place. This RoomDatabase object is temporary too.
So, on this moment we have already created DB: part of the tables (that are not migrated) will be created by SQLiteOpenHelper, other - by RoomDatabase.
Create RoomDatabase object for version X+2 without fallbackToDestructiveMigration. And this object we are going to use in our application.
Create SQLiteOpenHelper object for version X+2, that will just use created DB (migration from X+1 to X+2 are not required at all, because tables was created by Room at step 2). And this object we are going to use in our application.
In my (Android) project we have an ContentProvider per database table.
Every ContentProvider extends AbstractContentProvider, which has some virtual methods which gets some information about the database table (e.g. the table column names). Thanks to this, we can have some nice checks during insert/delete/etc operations on each table ContentProvider.
But on the other hand, adding a new database table consists of writing a lot of redundant code - after writing a schema we need to create a ContentProvider with analogous among different tables methods and add it to the manifest.
We would like to get rid of this boilerplate and to be able to retain current behavior. Can this be done? A solution we thought we'd use was to first change all ContentProviders AUTHORITIES to the same one and register only one contentProvider in manifest, but this apparently is not possible.
Do you have any other ideas to achieve this goal?
you should ideally use single content provider and expose multiple URIS - one for each table.
Implementation for CRUD methods for all the URIs are similar and can be done in a generic way. No code duplication is required to handle multiple URIs. Reason being SQliteDatabase has similar APIs/parameters that maps with ContentProvider API parameters
I have an app which requied more than one table.
The DB is mosly for read purposes and i want to know what is the best way to manage my tables.
I tought about 2 options.
Create new DB class with new DB for each table.
Create new table in the exits DB.
What is the best for better performance in reading?
hat is the best for better performance in reading?
For sure don't create new database but put all tables you need in one database. Reasons are more there, for instance now you don't know whether you will need sometime in a future to create some relations between these tables.
I's not "good" to have more db files which will represent one table, it's not comfortable and efficient as well. So my suggestion to you is to keep only one db file and put all tables in this one.
The best approach to manage SQLite database is to use SQLiteOpenHelper class that wraps all required logic for reading and writing from/to database. Then, SQLiteDatabase itself provides some API methods for inserting, updating and deleting from db.
At the end as my personal recommendation. If you'll have more than one table just how i mentioned create one SQLiteOpenHelper subclass for creating database and then for each table create object that will represent table "in objects" e.q. columns in table will become properties of object.
Finally for each table create DAO classes that will wrap CRUD operations and some specific methods for each table.
If you don't know how to start check these tutorials:
Android SQLite Database and ContentProvider - Tutorial
Android SQLite Database Tutorial
You can use SQLiteDatabase.
SQLiteDatabase has methods to create, delete, execute SQL commands, and perform other common database management tasks.
Database names must be unique within an application, not across all applications.
Read: Documentation
I'm developing an Android application that access many tables from a SQLite database.
I need an example to see how implement a database framework to access multiples tables. I've been looking for and I only find examples with one table.
UPDATE:
With one table I found only one class DBAdpater with object SQLiteDatabase and a class myDbHelper extends SQLiteOpenHelper.
With many tables I think I need one DBAdapter for each table. So, I think I need to share SQLiteDatabase object between each DBAdapter, isn't it? To open database, close, execute SQL stament...
I think I need one DBAdapter because I don't want a enormous DBAdapter class.
Any suggestions?
Thanks.
The documentation describes the class as a helper object to create, open, and/or manage a database. Having that in mind wouldn't you say that the name is a little misleading?
I think calling it SQLiteHelper would be more misleading as this might encourage people to write their queries and data manipulation inside this class. This classes primary role is db creation, upgrading and opening.
Because it doesn't help you to do EVERYTHING with database (as SQLiteHelper supposed to do). It helps only to open/manage database connection.
http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html