Hi Folks,
this subject came up in a discussion i had with someone last week:
First off: Please no advice like "put the file (Image, Video, PDF, whatever) in a Folder on the Disk, and save the path to it in the DB"
I know that technique, but it doesn't help the discussion/experience exchange.
The discussion was:
Do you have the BLOB-Field in the same table as the rest ("1-Table-Design"), or do you create a separate table in a 1:1-Relation (ForeignKey=PrimaryKey) ("2-Table-Design")?
For all intents and purposes, the Blob-Field is not mandatory, meaning in the second scenario ("2-Table-Design") it would be either "one-to-one" or "one-to-none" relation
Declaring a ForeignKey as the PrimaryKey is also easy (ForeignKey with ON DELETE/UPDATE, but WITH Unique- and WITHOUT AutoIncrement-Attribute).
I was actually leaning to the 2-Table-Design for the following reasons:
1) I can fire off a "SELECT * FROM tbl_master WHERE SomeField=SomeValue" (And no: We're not discussing a SELECT * either ;), and the BLOB would not get pulled through the connection
2) Sharding, i could actually shard the BLOB-Table to a different harddisk
3) Fragmentation (For lack of a better word)?!? This one i'm not sure about, since it goes into the specs of Database-Technology i'm not familiar with (Paging, allocating Memory/Diskspace etc.).
My Gut-feeling tells me, that "Fragmentation" would be worse in the 1-Table-Design
Next:
How high would the penalty be in the 2-Table-Design, if (for whatever reasons) you have to use a JOIN on both tables?
I'm pretty sure, perfomance in the 1-Table-Design would be miles ahead
As a last: In the 1-Table-Design, does it matter, where your BLOB-Column is? As in: the ordinal order?
My gut-feeling also tells me, the best place for a BLOB-Column would be as the last column in a table, but again: not something i'm familiar with
Thoughts? Experience?
this subject came up in a discussion i had with someone last week:
First off: Please no advice like "put the file (Image, Video, PDF, whatever) in a Folder on the Disk, and save the path to it in the DB"
I know that technique, but it doesn't help the discussion/experience exchange.
The discussion was:
Do you have the BLOB-Field in the same table as the rest ("1-Table-Design"), or do you create a separate table in a 1:1-Relation (ForeignKey=PrimaryKey) ("2-Table-Design")?
For all intents and purposes, the Blob-Field is not mandatory, meaning in the second scenario ("2-Table-Design") it would be either "one-to-one" or "one-to-none" relation
Declaring a ForeignKey as the PrimaryKey is also easy (ForeignKey with ON DELETE/UPDATE, but WITH Unique- and WITHOUT AutoIncrement-Attribute).
I was actually leaning to the 2-Table-Design for the following reasons:
1) I can fire off a "SELECT * FROM tbl_master WHERE SomeField=SomeValue" (And no: We're not discussing a SELECT * either ;), and the BLOB would not get pulled through the connection
2) Sharding, i could actually shard the BLOB-Table to a different harddisk
3) Fragmentation (For lack of a better word)?!? This one i'm not sure about, since it goes into the specs of Database-Technology i'm not familiar with (Paging, allocating Memory/Diskspace etc.).
My Gut-feeling tells me, that "Fragmentation" would be worse in the 1-Table-Design
Next:
How high would the penalty be in the 2-Table-Design, if (for whatever reasons) you have to use a JOIN on both tables?
I'm pretty sure, perfomance in the 1-Table-Design would be miles ahead
As a last: In the 1-Table-Design, does it matter, where your BLOB-Column is? As in: the ordinal order?
My gut-feeling also tells me, the best place for a BLOB-Column would be as the last column in a table, but again: not something i'm familiar with
Thoughts? Experience?