NoSQL is the right way.
Store Files in a File System, Not a Relational Database.
EDIT: for Wernfried
Hi Wernfried and thank you for your comment.
When you want to save an image in
SQL Server you have to use the data type
VARBINARY(MAX) and actually bring the image into the database:
INSERT INTO adventureworks.dbo.myimages
FROM OPENROWSET(BULK N'C:\img\1.png', SINGLE_BLOB) AS T1
This means that in an RDBMS, the data would be in different rows stored in different places on disk, requiring multiple disk operations for retrieval. (unless you keep reordering them time by time and that would be very panful with images and documents).
NoSQL you have more versatility, you can use:
- Key-value data stores: any type of binary object (text, video, JSON document, etc.)
- Document stores: JSON, XML, and BSON documents.
- Wide-column stores: data in tables with rows and columns similar to RDBMS but a query can retrieve related data in a single operation
- Graph stores: graph structures to store, map, and query relationships, so that adjacent elements are linked together without using an index.
Normally for images or documents you would go for the first two: Key-value data stores or Document stores.
And how are these two types actually stored behind the curtains?
They are simply saved on a filesystem, with only the reference to the
image or document stored in NoSQL.
That's why many people prefer to call RDBMS "databases" and NoSQL "Search Engine" because what NoSQL simply do is just digging into terabits or petabits of JSON, log file, images, etc...
If you have the image
C:\img\1.png and you want to import it into SQL Server you have to save it as
But if you want to import
C:\img\1.png into NoSQL you just have to tell to the engine that the images are into the folder
C:\img\ and NoSQL is fine with that.
...and now we can all take out our knifes and baseball stick and start the fight.