Suppose outside the subject of this thread, but in the document.
----
Sustainability factors
Self-documentation:
"The database format incorporates technical and structural metadata
needed to interpret and manipulate the data itself. For example,
a database file will include the CREATE TABLE declarations that
define tables and columns. To the extent that meaningful names are
used for tables and columns, the nature and context of the data
may be recorded. However, there is no explicit structure within
the file for storing fuller descriptive and contextual metadata.
Nor is there a capability to embed in the file a metadata object
conforming to a schema outside the SQLite specification."
----
This constantly bites me. This morning I had to generate a fix
to correct context of exported SQL statements for a dump of data.
The numeric values were being quoted as strings so therefore when
imported back in, they would have been treated as strings instead of
numbers.
DROP TABLE IF EXISTS mySinkDBTable;
CREATE TABLE mySinkDBTable (
key_id1 INTEGER UNSIGNED NOT NULL,
key_id2 INTEGER UNSIGNED NOT NULL,
text VARCHAR
);
--
-- Dumping data for table mySinkDBTable
--
INSERT INTO mySinkDBTable (key_id1, key_id2, text) VALUES('1', '8', '51');
Corrected:
INSERT INTO mySinkDBTable (key_id1, key_id2, text) VALUES(1, 8, '51');
Since the user is allowed to store the metadata for the table
types, example above, it is difficult for tools too determine
the proper processing for the data. I understand the flexibility,
and perhaps typeof() would solve most of my issues, but it would
be nice to have metadata field type stored as INTEGER, REAL,
NONE, TEXT, or BLOB.
danap.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
