Yes, sometime for performance reasons you need to break the rules of
normalization.
I did think that if the blob was at the end of the record, sqlite
wouldn't read that part of the record unless asked to (so you aren't
gaining that much with the separate table).
If the second table is just the foreign key and the blog, I would think
that my idea of making the foreign key a unique index (maybe even the
primary key for that table), would give you most of what you want. Yes,
you could create a record in the other table without a corresponding
record in the blob table, but that is sort of needed to avoid chicken
and egg issues with creating new records (not sure when foreign key
requirements are tested), and sort of represents that the blob is
empty/not written yet.
On 10/14/17 12:35 PM, Stephen Chrzanowski wrote:
In this case, rules can be made to be broken. In the case of larger blobs,
I push those out to a different table, and enforce (Through my software,
not a unique constraint as mentioned) the one-to-one relationship. There
is no reason to keep the blob on a record that is queried constantly.
On Sat, Oct 14, 2017 at 6:37 AM, Richard Damon <rich...@damon-family.org>
wrote:
One way to make them build one to at-most-one relationships is too add a
unique index on the foreign key, then it can only occur once.
A True one-one relationship by the normailization rules says that they
should all be in the same record.
--
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
--
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
