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]
-----------------------------------------------------------------------------
