this is more of a question of theory than anything else. I am writing an android app that uses a pre-packaged database. The purpose of the app is solely to search through this database and return values. Ill provide some abstract examples to illustrate my implementation and quandary. The user can search by: "Thing Name," and what I want returned to the user is values a, b, and c. I initially designed the database to have it all contained on a single sheet, and have column 1 be key_index, column 2 be name, column 3 be a, etc etc. When the user searches, the cursor will return the key_index, and then use that to pull values a b and c.
However, in my database "Thing alpha" can have a value a = 4 or a = 6. I do not want to repeat data in the database, i.e. have multiple rows with the same thing alpha, only separate "a" values. So what is the best way to organize the data given this situation? Do I keep all the "Thing Names" in a single sheet, and all the data separately. This is really a question of proper database design, which is definitely something foreign to me. Thanks for your help!
There's a thing called database normalization http://en.wikipedia.org/wiki/Database_normalization. You usually want to avoid redundancy and dependency in the DB entities using a corresponding design with surrogate keys and foreign keys and so on. Your "thing aplpha" looks like you want to have a many-to-many table like e.g. one or many songs belong/s to the same or different genres. You may want to create dictionary tables to hold your id,name pairs and have foreign keys referencing these tables. In your case it will be mostly a read-only DB so you might want to consider creating indexes with high FILLFACTOR percentage don't think sqlite allows it to do though. There're many ways to design the database. Everything depends on the purpose of DB. You can start with a design of your hardware like raids/file systems/db block sizes to match the F-System's block sizes in order to keep the I/O optimal and where to put your tablespaces/filegroups/indexes to balance the i/o load. The whole DB design theory/task is really a deep subject which is not to be underestimated nor is a matter of few sentences in the answer of stackoverflow. :)
without understanding your data better here is my guess at what you are looking for.
table: product
- _id
- name
table: attribute
- product_id
- a
Related
As per the title,
I have been confused on how I would implement the following:
A FlashCard deck has a title, due date (both have been implemented).
However, it also contains a List of Cards.
A Card is made up of a question and answer.
Like this, Deck(title, duedate, flashcards). Cards(question, answer)
I have been thinking about using a dedicated typeconverter for this. However,
it can also get messy.
For example,
I was thinking of having a type converter which collects all the existing questions and answers into a concatonated csv string. Then it will deconvert this when transitioning back into the object.
This method seems quite complicated. Therefore, I was wondering what is the best practice per se, for this sort of thing.
Thanks...
I do think your problem is a database schema problem. So basically there are 2 solutions depending on how you want to use the cards.
1. If the card does not repeat in any deck or if each and every card is unique:
Then you can use this schema:-
For finding all cards for a particular deck say suppose "Deck 1" whose id is 1. You can use the SQL query "SELECT * FROM Cards WHERE Deck_id=1;"
Pros:
You will have to maintain only two tables.
Probably easy to write SQL Queries.
Cons
You cannot reuse any cards. All cards will be unique.
May require more storage space.
2. If the card repeats, or if you want to reuse a card:
Then you can use this schema:-
For finding all cards for a particular deck say suppose "Deck 1" whose id is 1. You can use the SQL query "SELECT * FROM Cards WHERE id IN(SELECT Cards_id FROM Deck_has_Cards WHERE Deck_id=1);"
Pros:
Saves a lots of storage space(if cards are not unique).
Cons
Queries become very hard to write
I will recommend you to check for better SQL queries than those I have written.
If you are using Room Database use #Query(<SQL>)...(I am not expanding on this many tutorials are available).
I will not recommend the way you are trying to store the cards as it will be not working with the A.C.I.D. properties of the database.
I put my data in 3 tables(Links, Images and PDF)
each table has columns(university, faculty, grade, and description,...)
I want to retrieve description column in the 3 tables.
where university, faculty, and grade equal to certain values.
and sort them with creation date.
how can I perform that query in parse?
I'm not familiar with Android, but I'm pretty sure Parse does not support "Join" in the way a SQL database does. You could nest the queries, performing the next one in the previous one's completion block.
However, if you regularly want to get data from those 3 tables, I'd suggest you make it 1 table instead, with a column "Content" instead of Link/Img/PDF. Images and PDFs would probably be stored as PFFiles anyway, and you can put link as either its own string column or putting it in a file. You could also add a column "type" if you want to be able to query a specific type, or just keep track of which columns contains which data.
Then you could query the "Content" class, on the keys you want.
I think this link might help you
https://parse.com/docs/js/guide#relations and it is quite simple and nicely explained . You can't do it directly in the database, though.
I am develop app that Store to a table some Todo tasks with a - Topics and sub-topics. I thought of two ways to do this action, but what is the best way recommended. Way number 1 : is to add to my table - column with the sub-topics names, and when i want to show this specific Topic just do a for loop query for him.
way number 2 : is create 2 tables that handle the topics is and names and the other one handle the sub-topics data.
If you are only going to have one tag on each row, then the first method is fine.
If you are going to allow multiple tags on a row, then use a junction table, which is the todo_tags table in the second approach. The junction table is the right method for storing lists of objects (tags) attached to another list.
I have in my db 2 table with a many to many relationship.
TAB_ARTICLES: {_ID, TITLE, BODY, DATE}
TAB_TAG: {_ID, NAME, COLOR, DATE}
TAB_ART_TAG: {_ID, ARTICLE_ID, TAG_ID}
I need to populate a ListView, one row for article and in every row I need to have a TextView for every label linked to that article. Like the following image
I think 2 solutions.
a. I use a CursorAdapter with a cursor made only on TAB_ARTICLE and than in every row I do a query to join the other 2 tables looking for all tags related at this article. This solution require a lot of db accesses.
b. I realize a temporary table
TABLE_TEMP: {ARTICLE_TITLE, ARTICLE_BODY, ARTICLE_DATE, TAG1_NAME, TAG1_COLOR, TAG2_NAME, TAG2_COLOR, ...}
and I use a query on this table as cursor for custom adapter. This solution use more space and have a limitation on possible displayed tags due to table columns.
Are there other ways?
Well, actually, it's a multicriterion thing: time, space, updates, search, etc. So there's no single recipe. It's very probable, however, that multiple queries will bog down scrolling. Worse, on some devices only. A temporary table may or may not be OK depending on the overall size of your data. And you may want to keep this redundant table in sync with the main one, making simultaneous updates to both.
One of the simplest trade-offs could be adding a redundant TEXT/CLOB column with the tag data (XML, JSON, other markup/separated format) to TAB_ARTICLES and keeping it in sync with your detail data. By the way, you will really need the M:M schema only if your queries substantiate that. Otherwise, the single table would suffice.
Again, I'd list and evaluate all the criteria first and decide what dimensions really need to be scalable and simplify the rest.
We have about 7-8 tables in our Android application each having about 8 columns on an average. Both read and write operations are performed on the database and I am experimenting and trying to find ways to enhance the performance of the DataAccess layer. So, far I have tried the following:
Use positional arguments in where clauses (Reason: so that sqlite makes use of the same execution plan)
Enclose inserts and update with transactions(Reason: every db operation is enclosed within a transaction by default. Doing this will remove that overhead)
Indexing: I have not created any explicit index other than those created by default on the primary key and unique keys columns.(Reason: indexing will improve seek time)
I have mentioned my assumptions in paranthesis; please correct me if I am wrong.
Questions:
Can I add anything else to this list? I read somewhere that avoiding the use of db-journal can improve performance of updates? Is this a myth or fact? How can this be done, if recomended?
Are nested transactions allowed in SQLite3? How do they affect performance?
The thing is I have a function which runs an update in a loop, so, i have enclosed the loop within a transaction block. Sometimes this function is called from another loop inside some other function. The calling function also encloses the loop within a transaction block. How does such a nesting of transactions affect performance?
The where clauses on my queries use more than one columns to build the predicate. These columns might not necessarily by a primary key or unique columns. Should I create indices on these columns too? Is it a good idea to create multiple indices for such a table?
Pin down exactly which queries you need to optimize. Grab a copy of a typical database and use the REPL to time queries. Use this to benchmark any gains as you optimize.
Use ANALYZE to allow SQLite's query planner to work more efficiently.
For SELECTs and UPDATEs, indexes can things up, but only if the indexes you create can actually be used by the queries that you need speeding up. Use EXPLAIN QUERY PLAN on your queries to see which index would be used or if the query requires a full table scan. For large tables, a full table scan is bad and you probably want an index. Only one index will be used on any given query. If you have multiple predicates, then the index that will be used is the one that is expected to reduce the result set the most (based on ANALYZE). You can have indexes that contain multiple columns (to assist queries with multiple predicates). If you have indexes with multiple columns, they are usable only if the predicates fit the index from left to right with no gaps (but unused columns at the end are fine). If you use an ordering predicate (<, <=, > etc) then that needs to be in the last used column of the index. Using both WHERE predicates and ORDER BY both require an index and SQLite can only use one, so that can be a point where performance suffers. The more indexes you have, the slower your INSERTs will be, so you will have to work out the best trade-off for your situation.
If you have more complex queries that can't make use of any indexes that you might create, you can de-normalize your schema, structuring your data in such a way that the queries are simpler and can be answered using indexes.
If you are doing a large number of INSERTs, try dropping indexes and recreating them at the end. You will need to benchmark this.
SQLite does support nested transactions using savepoints, but I'm not sure that you'll gain anything there performance-wise.
You can gain lots of speed by compromising on data integrity. If you can recover from database corruption yourself, then this might work for you. You could perhaps only do this when you're doing intensive operations that you can recover from manually.
I'm not sure how much of this you can get to from an Android application. There is a more detailed guide for optimizing SQLite in general in the SQLite documentation.
Here's a bit of code to get EXPLAIN QUERY PLAN results into Android logcat from a running Android app. I'm starting with an SQLiteOpenHelper dbHelper and an SQLiteQueryBuilder qb.
String sql = qb.buildQuery(projection,selection,selectionArgs,groupBy,having,sortOrder,limit);
android.util.Log.d("EXPLAIN",sql + "; " + java.util.Arrays.toString(selectionArgs));
Cursor c = dbHelper.getReadableDatabase().rawQuery("EXPLAIN QUERY PLAN " + sql,selectionArgs);
if(c.moveToFirst()) {
do {
StringBuilder sb = new StringBuilder();
for(int i = 0; i < c.getColumnCount(); i++) {
sb.append(c.getColumnName(i)).append(":").append(c.getString(i)).append(", ");
}
android.util.Log.d("EXPLAIN",sb.toString());
} while(c.moveToNext());
}
c.close();
I dropped this into my ContentProvider.query() and now I can see exactly how all the queries are getting performed. (In my case it looks like the problem is too many queries rather than poor use of indexing; but maybe this will help someone else...)
I would add these :
Using of rawQuery() instead of building using ContentValues will fasten up in certain cases. off course it is a little tedious to write raw query.
If you have a lot of string / text type data, consider creating Virtual tables using full text search (FTS3), which can run faster query. you can search in google for the exact speed improvements.
A minor point to add to Robie's otherwise comprehensive answer: the VFS in SQLite (which is mostly concerned with locking) can be swapped out for alternatives. You may find one of the alternatives like unix-excl or unix-none to be faster but heed the warnings on the SQLite VFS page!
Normalization (of table structures) is also worth considering (if you haven't already) simply because it tends to provide the smallest representation of the data in the database; this is a trade-off, less I/O for more CPU, and one that is usually worthwhile in medium-scale enterprise databases (the sort I'm most familiar with), but I'm afraid I've no idea whether the trade-off works well on small-scale platforms like Android.