Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Programming
 Storing and comparing images in SQL server 2008

Author  Topic 

rama8301
Starting Member

1 Post

Posted - 2010-04-10 : 16:18:07
I am trying to build a small e-commerce website that will allow user to upload and store the image of their product in the database and also the user could upload the image of the product and compare it with all the similar product images in the database.
I am using MS .Net as the front end.
So please let me know if MS SQL server is the best option to carry out such task or should I consider some other database to do this in terms of complexity involved as well the integration with MS .Net framework.
I am new to databases so please explain in detail how to approach and which db to use.Thanks!!

Kristen
Test

22859 Posts

Posted - 2010-04-11 : 02:19:54
Don't know about image comparison, but for images for (public, rather than restricted) use on a web site I would always use the web server's filespace for images.

There are very few, specialised, situations where I would want to use SQL Server to store images.

By all means store the image name, file path, Height & Width, ALT text, etc. in the database (so you can related the Images PK with the Product(s) it is associated with. You may also want to store Filesize and a CRC so that you can quickly see if another image can NOT be the same, then you will be left with deciding if they are actually identical (for which I imagine a byte-compare is the only truly 100% method).

Other than that I'm not sure how you will detect "similar product images" (unless you mean other images associated with that product, in which case the Filename / Path suggest will be fine)
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-04-11 : 02:21:31
quote:
Originally posted by Kristen

Don't know about image comparison, but for images for (public, rather than restricted) use on a web site I would always use the web server's filespace for images.

There are very few, specialised, situations where I would want to use SQL Server to store images.

By all means store the image name, file path, Height & Width, ALT text, etc. in the database (so you can associate the Images' PKs with the Product(s) it is associated with). You may also want to store Filesize and a CRC so that you can quickly see if another image can NOT be the same, then you will be left with deciding if they are actually identical (for which I imagine a byte-compare is the only truly 100% method).

Other than that I'm not sure how you will detect "similar product images" (unless you mean other images associated with that product, in which case the Filename / Path suggest will be fine)

Go to Top of Page

madhivanan
Premature Yak Congratulator

22864 Posts

Posted - 2010-04-12 : 02:52:29
quote:
Originally posted by Kristen

quote:
Originally posted by Kristen

Don't know about image comparison, but for images for (public, rather than restricted) use on a web site I would always use the web server's filespace for images.

There are very few, specialised, situations where I would want to use SQL Server to store images.

By all means store the image name, file path, Height & Width, ALT text, etc. in the database (so you can associate the Images' PKs with the Product(s) it is associated with). You may also want to store Filesize and a CRC so that you can quickly see if another image can NOT be the same, then you will be left with deciding if they are actually identical (for which I imagine a byte-compare is the only truly 100% method).

Other than that I'm not sure how you will detect "similar product images" (unless you mean other images associated with that product, in which case the Filename / Path suggest will be fine)




Did you want to add some more points?

Madhivanan

Failing to plan is Planning to fail
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-04-12 : 04:05:06
Sorry ... second one was fixing some typos, meant to press EDIT rather than REPLY - so please read second one, rather than first.
Go to Top of Page
   

- Advertisement -