I'm using a SQL database to store a single float value, and I'm really having trouble getting my brain around everything that needs to be done to make it work. I've been reading the NotePad tutorial Google provides for a few days now and Googling around but it just isn't clicking in my head.
Could anyone explain to me (no code needed) just what exactly I need to have for a simple database, and how to read the value from it into my float variable and how to write the value of the variable back to the table?
Much thanks, I think my brain is starting to seep out my ears.
A SQL database is not a very good way to store a single float value. It's overkill. Instead, I recommend just using Android's SharedPreference class, which provides a simple key-value store.
If you're still going to create a database, what you need is:
The database file.
A SQL schemea for that database file. This describes the tables in the database, as well as the columns. If you're just storing a single float, then you could just create a single table ("data"), with two columns ("key", "value") -- like SharedPreferences, we're just implementing a key-value store of our own (another reason not to do this -- you're reinventing the wheel).
Once that's created, you can just insert a record with some arbitrary key ("myFloat") for lookups later and your chosen value.
So, your initial SQL statement would look something like this:
INSERT INTO data (key, value) VALUES ("myFloat", 3.14);
Later, you'd retrieve it with a SELECT statement:
SELECT key, value FROM data WHERE key="myFloat";
And you can update the value with an UPDATE statement:
UPDATE data SET value=3.14 WHERE key="myFloat";
It is as simple as shown above or just try reading more on SQL queries
Related
I have an app already in production, and now I want to change database property names in several tables to reduce bandwidth.
For eg, realtime database existing property is:
purchasePrice: 60
and by using #PropertyName, I want to change it so it now looks like this:
pp: 60
The changed POJO now has #PropertyName like:
#PropertyName("pp")
public float purchasePrice;
The question is: What is the best migration strategy so that all existing 'purchasePrice' is updated to new name in the realtime database, i.e 'pp' in this example case?
One naive approach I can think of is, on app update at client end, pull all data using old POJOs and assign each property to new POJOs (newPOJO.pp = oldPOJO.purchasePrice) and then save it in DB. But there should be a better way, as I have many POJOs.
Thanks,
If you want to change the name of a field in the database everywhere it occurs, there is really no easy way to do this. You're going to have to:
Query all of the nodes where it could appear
Check to see if the field needs to change
Write the new data back to that location
Whether you do that with code that uses #PropertyName or something more generic, it doesn't really matter.
I am trying to create sqllite db for my Android application use
Is it bad habit to have all the data types as text? The reason is even though some data can be integer in nature (like number of items.. Etc) but many times I need to display the values as a string or get it as input from user. So I thought for easier manipulation I will just make the datatype in the db as text
Thoughts?
The first thing to understand here is SQLite Storage Classes. SQLite allows any data type to be stored in a table's columns, the actual data type defined by the table is just a hint to the database engine.
This means that even if you define a column as type INTEGER, you can still store text in it.
That being said, I haven't found a use case for storing arbitrary data types in a column, or a case for disregarding the defined data types. For readability purposes, it would probably be a good idea to type things properly and obey the defined types.
I maintain an application that is collecting a lot of information and is storing these information in an ArrayList.
In detail this ArrayList is defined as ArrayList<FileInformation> which has some member like:
private File mFile;
private Long mSize;
private int mCount;
private Long mFilteredSize;
private int mFilteredCount;
private int mNumberOfFilters;
etc.
This approach is working but is not very flexible when I would like to introduce some new functionality. It also has some limitations in terms of memory usage and scale-ability. Because of this I did some tests if a database is the better approach. From the flexibility there is no question, but somehow I'm not able to make it running fast enough to become a real alternative.
Right now the database has just one table like this:
CREATE TABLE ExtContent (
"path" TEXT not null,
"folderpath" TEXT not null,
"filename" TEXT,
"extention" TEXT,
"size" NUMERIC,
"filedate" NUMERIC,
"isfolder" INTEGER not null,
"firstfound" NUMERIC not null,
"lastfound" NUMERIC not null,
"filtered" INTEGER not null
);
The performance issue is immense. Collecting and writing ~14000 items takes ~3mins! when writing into the database and just 4-5secs if written into the ArrayList.
Creating the database in-memory does not make a big difference.
As my experience in terms of SQLITE is rather limited, I started by creating the entries via the android.database.sqlite.SQLiteDatabase.insert methode.
As there was no meaningful difference between a file based and a in-memory database, I guess using BEGIN TRANSACTION and COMMIT TRANSACTION will not make any difference.
Is there some way to optimize this behavior?
Just for clarification, putting BEGIN TRANSACTION and END TRANSACTION will increase the performance greatly. Quoted from http://www.sqlite.org/faq.html#q19 :
SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. By default, each INSERT statement is its own transaction...
I had a similar issue on an app I was coding on the weekend.
Is the data in the database to be included in the app when it's released? If so, bulk inserts aren't they way to go, instead you want to look at creating the database and including it in the assets directory and copying it over to the device. Here's a great link.
Otherwise I'm not sure you can do much to improve performance, this link explains methods on bulk inserting into an SqlLite Database.
Edit: You may also want to post your insert code too.
This is opretty obvious. Assuming you already allocated object to insert into. ( This is the same workload for bot solutions ) Let's compare alternatives:
Inserting in ArrayList does:
- (optional) allocate new chinks of cells for pointers if necessary
- insert object pointer into array list on the end
... really fast
INserting into sqlite:
-prepare insertion query ( I hope you use prepared query, and do not construct it from strings)
-perform database table insertion with modifications of indexes etc.
... a lot of work
Only advantage of database is that you can:
- query it later
- it handles external storage transparently allowing you to have much more entities
But it comes at cost of performance.
Depending on what you are for, there could be better alternatives.
For example, in my android games I store highscore entries in JSON file and utilise
GSON Pull parser / databinding layer ( https://github.com/ko5tik/jsonserializer ) to create objects out of it. Typical load time for 2000 entries from external storage is about 2-3 seconds
So my fundamentals of creating and manipulating databases are a bit messed up. My aim here is that whenever the app is launched, the user is allowed to specify a table name, and whatever data is then collected is put into that table.
However, I'm confused as to how to do this. Do I simply pass the value of a user entered variable as the table name in my contentprovider class and execute sqlite statements to create it?
I've read/reading the documentation already, so if anyone has any insight or clarity, or even better, code snippets, it would be great.
Why not simply use one table, and create a value that stands for the current app-session, and insert that value with each row. This would make your code simpler, and would still allow you to segregate/filter out the values from a particular app-session. If you want to give the user the ability to enter the value (as you are giving them the ability to choose the table name) you'd just want to check to see if that value had already been used, just as you would have to see if the table-name had already been used.
Here's the situation. I have a bunch of objects that implement Serializable that I want to store in a SQL database. I have two questions
Is there a way to serialize the object directly into the database
Is that the best way to do it or should I
Write the object out to a formatting String and put it in the database that way and then parse it back out
Write each member to the database with a field that is unique to each object
Its generally not a good idea to try and put any sort of object (serialized/deliminated) in your SQL because modifying them is always a bitch.
It sounds like you're on the right track with idea 2. Is this a one-to-many situation? (because then a xref would obviously be the right answer) or even a foreign key would be better. cheers.
I'd still have a table per class + simplistic DAO.
If you absolutely want to do it wrong :), then serialize to JSON and persist the resulting string.
You could store the objects directly using db4o:
http://www.db4o.com/Android/default.aspx