I am kind of stuck in dilemma, I am making an application which consist of multiple tables/entities and I am using Content Provider to manage my sql data. Almost every table in db has a relation with other table.
Now I am really confused whether I should make a single content provider, stuff it with 9,10 tables and use it. Or should I make a separate content provider for every single table and use it.
I can handle join queries between tables in both ways as well. Can anyone give me pros and cons for both approaches? and guide me in the right direction ?
Any kind of help, would be highly appreciated.
If the tables relate to each other and presumably you would like to do joins then you should do one content provider and not multiple. I assume if the tables relate then you will be wanting to do joins on data or at the very least enforce foreign key constraints.
Also for doing joins the best way. In my opinion to do them is to create a view. Treat it kinda like a table. You can query it like a table also. Just my advice. If your still interested in this I can go into more detail.
Related
I am doing application for learning words in foreign language, so I have this words stored in my database. These words are separated for example into 3 levels of difficulty. Every level is made of some groups of words, these groups introduces TABLES of SQLite db. I am using SQLiteOpenHelper as communication between application and databases.
Now my question. What is better?
Make 3 smaller databases, each for every level and use own
SQLiteOpenHelper, so together 3 dbs with 3 open helpers.
Make 1 large database, where will be that 3 levels, which means
many TABLES, but just only 1 SQLiteOpenHelper.
Thanks for any advice or opininon.
I suggest 1 large database (DB).
You should not be worried about making large DBs, DBs are invented to store a large amount of data (and even many-many tables). It is much easier to create and maintain one DB than multiple ones and your code will be much clearer using one DB.
And I don't know your program, but I would go even further: I would rather store all words in the same table if you store the same information of them, and add a column to show the level and another one to show the group which they belong to.
The main idea of SQL is that you don't really care how much space your DB will require and how much time it gonna take to find the result of a query because DataBase Managent Systems (in your case the SQLiteOpenHelper and SQLite) are insanely efficient considering space and time. Instead you should rather concentrate on designing a system that can be expanded easily (for example if you want to add another column to tables containing words (e.g. you want to store a new information about words) or want to add new levels or groups in a later stage of development) and has clear structure. You might lose a few milliseconds separating groups and levels via the SELECT command of SQL, but your DB will be much more flexible - you can add levels and groups and add more information about words with ease. The key of desinging a good DB: You should store different kind of data in different tables and same kind of data in same table...
The error that you mention in your comment is almost certainly a bug in your application code. There is no reason that an application with multiple databases should encounter that sort of error.
That said, my answer to your original question is that it is objectively "better" to use a single database.
It is better because you will have less code to maintain, no possibility of attempting to access the wrong database in a given situation, and the code will be more idiomatic - i.e. there's no benefit to using multiple databases, so if you were to use multiple databases, anyone reading your code would spend a lot of time trying to figure out why you did it.
I am creating my first Android app, a random number generator. For my design, I need to create a sqlite table that has 1,348,621,560 rows with around 16 columns each. I need all rows available at all times, but without relational data. The table will not grow, and I will only run simple queries that scan the table and return a few records.
My question:
Is this even possible? I've looked into partitioning tables, sharding, keeping the table in one piece, etc.. If this is possible, what is the best way to maintain efficiency and reliability?
UPDATE:
Lots of responders have informed me that this approach is not the most elegant nor the most efficient. However, I have found information that PostgresQL can easily handle the amount of data I will create. Thanks to everyone who responded!
I am trying to build a local database for android. I am a little lost.
The app is a document management app.. I need to save the following...
Document
--------
Id
import date
List<DocTags>
extension
etc
then I have a number of docTags that have different information
Location
-------
id
name
lat
long
Company
------
Id
name
Street
town
around 10 other doc types.
I realise I need a table to store all the docTag ids that are assigned to a document but these relate to lots of different tables. My problem is that I need to retrieve a list of documents by searching for the doctag Id or multiple doctag ids. We need to assume we have 10,000 documents of more which could equate to 40,000 doc tags. So performance is a major issue. What is the best way to structure the database?
I will also need to search the doctag names.
Thanks
I'd have a many to many JOIN table relating Document to Tag.
I would not have those tags in multiple tables. That breaks first normal form. If other tables need to refer to Tag rows, give them JOIN tables as well.
Your comments below suggest that either a normalization refresher is necessary or that a relational model might not be the best choice for your problem. Perhaps a NoSQL, document based solution would fit better.
I'm only ever used SQLite once or twice, but based on my experience with other
database systems, I would strongly recommend starting with a solid relational schema,
and assessing the performance, before trying anything else.
In your case, I think the schema would look like this.
(Of course with two additional tables for each doctag).
You will have a lot of tables, and probably quite a long query to get all the information,
but this is not necessarily a bad thing. Having the schema relational will allow the query
optimizer to do its job, and will make future queries much easier to write.
A query to get the document, and any information on it's location and company (or return
null if the document does not have this tag) would look like this:
SELECT * FROM Document
LEFT JOIN DocumentLocation ON Document.ID=DocumentLocation.DocumentID
INNER JOIN Location ON DocumentLocation.LocationID=Location.LocationID
LEFT JOIN DocumentCompany ON Document.ID=DocumentCompany.DocumentID
INNER JOIN Company ON DocumentCompany.CompanyID=Company.CompanyID
If the performance of this does turn out to be too slow, you can then investigate strategies for improving the performance (e.g. caching, additional indexes) depending on the expected usage pattern of your application.
Can someone help in writing a Custom Content Provider for Multiple tables. I can write for a single table but for multiple table I did not find any good example.
A near duplicate of an existing answer. Compare this question and answer, discussing use of LEFT JOIN inside your ContentProvider.
Note that, all in all, the expected use of ContentProviders is to use single tables for each path in your Content URI. It's still seen as something out of the norm to use join or index multiple tables in one call. Not to say it's bad, just that there aren't many people thinking in those terms.
Not sure of the absolute utility of this but seems as though it should be possible and useful.
Can you extend ContentProvider to provide URIs representing new queries (i.e., joins across multiple tables not specified by existing URIs) for an existing system database?
The alternative seems to be that I need to write a series of cursor queries then join them -- seems like a lot of unnecessary code duplication.
I have been trying this for the contacts database as an exercise, but no love so far.
The crux seems to be that I cannot open a database in another package during the setup phase.
Am I just completely out in left field here?
It's possible as I am new to both Java and Android.
Comments and/or pointers to relevant resources are appreciated.
Thanks,
Steve
Can you extend ContentProvider to
provide URIs representing new queries
(i.e., joins across multiple tables
not specified by existing URIs) for an
existing system database?
Not really, only because you don't have direct access to existing system databases, in terms of SQLite. Now, creating a ContentProvider that performs your joins for you, as a reusability measure, is certainly doable, though I would get worried about the performance overhead of multiple cross-process hops.