I have a site where users can save images together with a couple of info fields about the image. The images are stored as binary data in the same table as the rest of the image info. So far pretty standard.
Now, the users should be able to upload a document, describing the image in more detail, along with the rest of the image and its’ info. Size ~2MB per document.
My question is: Should I store this document (binary data) in the same table as the rest of the images or should I create a new table holding only the documents. There would of course be an id reference in the image table to the document in the document table.
I have a search function joining a couple of tables, including the image table, when searching for images. I need to know if there’s a difference in efficiency between these two solutions.
I always fetch the document data separately but if I don’t win anything in having the documents in a separate table I’ll just put it with the rest of the image info.
I’m asking this since I don’t really know how SQL Server handle tables when joing and searching in them.
I have about 10´000 users with a maximum of 10 images per user. (ASP.NET – SQL Server)
(I’m not asking if I should store documents in the database, but how 😉
Thanks in advance!
/zalk
Edit
Example 1:
columns in imageTable – id, title, dateAdded, image (binary data), document (binary data)
Searching for items from a specific user I would join the userTable and the imageTable and select title where image id equals user id.
So, will there be any difference in the performance if the document is in the imageTable or in an own table?
The metainformation about the image is information about the image. Hence; it should be part of the same table. Though there may be an argument if the metadata is used separately from the image.
Also, it is not uncommon to store the (relative) path to which the image file is stored in the database. This has the extra advantage that the path at which the image is stored can be served statically; rather then queried from a database and interpreted by ASP.