Subject | DB Design Question - include large blob in master table, or separate table |
---|---|
Author | Maya Opperman |
Post date | 2008-01-30T08:17:17Z |
Hi,
I am about to add a potentially very large blob field to one of my
tables for the storing of images for stock items.
My instinct would be to simply add the new blob field to the existing
table which contains the stock data. What is worrying me though, is some
users may have added a "select * from MasterTable where StockCode =
:StockCode" dataset to their reports in order to pick up some stock
info. There may be some serious speed degradation on reports where this
has been done (I presume?).
Also, when editing a stock record, if the large field was in a separate
table, it would make it much easier to control the updating of the image
separately and only when the image gets modified, without having to
worry about locking issues.
There will only ever be one image for each stock item, and images will
never be shared amongst stock items.
Would putting the blob in a separate table be considered good database
design, or an atrocious big no-no?
Thanks
Maya
[Non-text portions of this message have been removed]
I am about to add a potentially very large blob field to one of my
tables for the storing of images for stock items.
My instinct would be to simply add the new blob field to the existing
table which contains the stock data. What is worrying me though, is some
users may have added a "select * from MasterTable where StockCode =
:StockCode" dataset to their reports in order to pick up some stock
info. There may be some serious speed degradation on reports where this
has been done (I presume?).
Also, when editing a stock record, if the large field was in a separate
table, it would make it much easier to control the updating of the image
separately and only when the image gets modified, without having to
worry about locking issues.
There will only ever be one image for each stock item, and images will
never be shared amongst stock items.
Would putting the blob in a separate table be considered good database
design, or an atrocious big no-no?
Thanks
Maya
[Non-text portions of this message have been removed]