My idea was to fill up that base, and afterwards exploit the data: i want to
be able to find the most recurrent profiles. Are there complex statistical
tools that would work with sqlite's data format ? Or am i forced (as i
suppose) to do everything? I'm particularly looking for
market-partitioning-like data mining processes.
Are there any I/O features within sqlite, such as csv exporting? I may want
to visualize charts in order to decide the best decision algorithms.
Anyway thanks a lot for your (clear and good) ideas :)
On 11/14/06, Trevor Talbot <[EMAIL PROTECTED]> wrote:
On 11/14/06, Florent THIERY <[EMAIL PROTECTED]> wrote:
> If i follow your saying, it would be best to create a new table when i
> encounter a new file-structure scheme, but keep a general purpose table
with
> minimal and univeral information.
Just to clarify, for simple key-value style headers I mean having two
tables period: universal information, and everything else (hopefully
the ASCII art comes out):
images
+---------------------------------+
| fileid filename width height |
+---------------------------------+
| 1 foo.jpg 640 480 |
| 2 bar.jpg 600 200 |
+---------------------------------+
headers
+-------------------------------------------+
| fileid path value |
+-------------------------------------------+
| 1 /sof/content/nr_components 1 |
| 1 /sof/content/component1 val1 |
| 2 /sof/content/nr_components 0 |
| 2 /new/header/type/one val1 |
| 2 /new/header/type/two val2 |
+-------------------------------------------+
The "images" table is the convenient one-row-with-all-the-info form.
The "headers" table is a bit more work to use, but is flexible enough
to handle arbitrary headers without changing your schema (just the
query conditions).
Retrieving all the headers for "bar.jpg":
SELECT path, value FROM headers JOIN images USING (fileid) WHERE
images.filename = 'bar.jpg';
And you can just iterate through the result rows.
Of course if you need to represent header types that don't fit well in
that key-value form, a different table for them is quite appropriate.
> It allows me to distinguish clearly the types of organization.
Exactly :) It is more work, but it allows relational queries to do
what they do best.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
