[android-developers] Re: Display list of saved tables to be opened

2011-04-23 Thread Robert
Well I would put the names into a table that you can read (and maybe
some descriptive info too)  but you didn't look far to find your
answer.

A quick google for  sqlite select tables found:
http://www.sqlite.org/sqlite.htmlin there is a section Querying
the database schema   go read that and you'll find a SELECT that does
exactly what you want (actually more than you probably need).

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


[android-developers] Re: Display list of saved tables to be opened

2011-04-23 Thread Bob Kerns
It's a database design question, not an Android question. That's not evading 
answering you -- it's probably the most helpful thing I'll tell you! 
Understanding that your question really has nothing in it related to Android 
will help you find the information you need, beyond anything I can tell you.

It's also a fairly basic database schema design problem. You clearly don't 
know the basics of how to design the schema for a database -- so that's what 
you need to go learn. That's really important knowledge for any programmer 
these days, so it'll be well worth your time.

With that said, I'll try to get you started, to connect your problem to the 
concepts.

SQL (and SQLite) databases are *relational* databases. That means, each 
table defines a set of relationships, and you represent your data in terms 
of the relationships. Each table defines a particular type of relationship; 
each column in a table defines a particular role in the relationship; each 
row is a separate relationship of that type.

Generally, I would NOT save each project in a separate table in the 
database. Let's look at the concrete concepts you have. (These are sometimes 
called entities in database design).

1) Project.
2) A main 2D array. You don't say clearly what it contains, but I infer it 
may be a 2D array of strings, so I'll go with that.
3) A parallel 2D array A. Again, it's a bit unclear, but it appears it may 
be also a 2D array of strings.
4) A parallel 2D array B -- likewise.

So let's define our tables. I'm going to assume that we want fully-general 
2D arrays here, of arbitrary size and content, and that we'll actually use 
the database to represent them. That will illustrate databases a bit better 
than the alternative of encoding your data into a big string, and decoding 
it after you retrieve it.

I'm NOT going to go into the details enough to give you a concrete schema -- 
partly to save my time, and partly because you need to go read up on that 
anyway.

The logical place to start here is the Project table. But I'm not going to 
do that, because I want to illustrate a thinking process and strategy you 
need to be able to go through, called normalization. So if you are feeling 
that's where we should start, you're right, but be patient.

Let's instead start with your main 2D array. A 2D array is logically a 
relationship between two positive integer coordinates -- let's call them I 
and J -- and a value, which we'll call V since I don't know what your data 
means. Further, each of these bits of data is associated with a project, 
let's call that Project_Name

So we have the following Array_Main
Project_Name I J V
Work 0 0 Elephant
Work 0 1 Fish
Work 0 2 Cow
Work 1 0 Pig
Work 1 1 Sheep
Work 1 2 Horse
Play 0 0 Cat
Play 0 1 Dog
Play 1 0 Hamster
Play 1 1 Iguana

OK, you can see we've represented two projects here and their main arrays, 
of two different shapes. We can do things like:

SELECT I, J, V FROM Array_Main
WHERE Project_Name = 'Work'

to get all of the main data for the project named 'Work'.

We can also select just a part of it, for example:

SELECT I, J, V  FROM Array_Main
WHERE Project_Name = 'Work'
AND  I  2 AND J  2;

(Thus illustrating we can store and use more data than we need to actually 
load at any one time).

Now we can do the same for the other two arrays, in two additional tables, 
Array_A and  Array_B.

OK, now let's take a look at what we have -- we have a piece of duplicated 
information in every row, in three tables -- the Project_Name. Collapsing 
this sort of duplication is called normalization.  It's a whole topic of 
its own, but here what we want to do is pretty simple: Replace this string 
with a project ID, and have a separate table that establishes the 
relationship between project ID and name.

This has a number of benefits, most of which I won't go into -- but one very 
obvious one is, you can now rename the project, without  touching every data 
row in the database! It's also more efficient, extensible, etc. etc.

So now we have a table Project:
Project_ID Project_Name
 1 Work
 2 Play

and Array_Main (and _A and _B):
Project_ID I J V
1  0 0 Elephant
1  0 1 Fish
1  0 2 Cow
1  1 0 Pig
1  1 1 Sheep
1  1 2 Horse
1  0 0 Cat
1  0 1 Dog
1  1 0 Hamster
1  1 1 Iguana

Now, we can select our main data thus:

SELECT I, J, V  FROM Array_MAIN
INNER JOIN Project ON Array_Main.Project_ID = Project.Project_ID
WHERE Project_Name = 'Work';.

We can even write:

SELECT Array_Main.I, Array_Main.J, Array_Main.V as MAIN, Array_A.V as A, 
Array_B.V as B FROM Project
INNER JOIN Array_Main ON  Project.Project_ID = Array_Main.Project_ID
INNER JOIN Array_A ON Project.Project_ID = Array_A.Project_ID AND 
Array_Main.I = Array_A.I AND Array_Main.J = Array_A.J
INNER JOIN Array_B ON Project.Project_ID = Array_B.Project_ID AND 

[android-developers] Re: Display list of saved tables to be opened

2011-04-23 Thread Bob Kerns
Generally speaking, if you need to query the schema at runtime, you're 
probably not making good use of SQL -- unless you're making some sort of 
schema-agnostic general tool.

Creating a table per project is not generally a good approach. It really 
doesn't let the database be a database, and may be very inefficient for 
creating/deleting projects, doesn't give you the referential integrity that 
you'd get with a foreign key constraint, etc.

Still, knowing how to examine the schema is a very useful skill during 
development!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Display list of saved tables to be opened

2011-04-22 Thread ZitZ
Well, clearly it relates to android because I'm trying to display a
list of those tables in the UI to the user, so the user could select
which one he/she wants to load. I don't think that will be in the SQL
documentation for some reason.

It is clearly an overlapping issue, but something I suspect is done
often, but examples/documentation is scarce.

On Apr 21, 6:40 am, lbendlin l...@bendlin.us wrote:
 how is this related to Android?  Read the SQLite documentation.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


[android-developers] Re: Display list of saved tables to be opened

2011-04-21 Thread lbendlin
how is this related to Android?  Read the SQLite documentation.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en