Store Images In SQL Table
-
I'm working on a WPF app that has user profiles. The profile contains the user's picture. Any reason not to store the image in the Profiles table? Never done this before. Suggestions/comments appreciated. Thanks
Everything makes sense in someone's mind
-
I'm working on a WPF app that has user profiles. The profile contains the user's picture. Any reason not to store the image in the Profiles table? Never done this before. Suggestions/comments appreciated. Thanks
Everything makes sense in someone's mind
Kevin Marois wrote:
Any reason not to store the image in the Profiles table?
I don't have any; that's what I'd do. If you're not already, you may want to resize the images to some standard before doing so.
-
Kevin Marois wrote:
Any reason not to store the image in the Profiles table?
I don't have any; that's what I'd do. If you're not already, you may want to resize the images to some standard before doing so.
Ok, thanks
Everything makes sense in someone's mind
-
I'm working on a WPF app that has user profiles. The profile contains the user's picture. Any reason not to store the image in the Profiles table? Never done this before. Suggestions/comments appreciated. Thanks
Everything makes sense in someone's mind
If you were working on a webapp, then it'd be sweeter to have them on the server directly so that the browser can cache them. Outside of that environment, I prefer to store those things in the database. That way you can backup all the data that belongs together in a single document.
Bastard Programmer from Hell :suss:
-
If you were working on a webapp, then it'd be sweeter to have them on the server directly so that the browser can cache them. Outside of that environment, I prefer to store those things in the database. That way you can backup all the data that belongs together in a single document.
Bastard Programmer from Hell :suss:
Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
Everything makes sense in someone's mind
-
Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
Everything makes sense in someone's mind
The problem I have with that is if someone replaces a file with one you don't expect.
-
Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
Everything makes sense in someone's mind
Kevin Marois wrote:
Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
I'd still store them in a database :-\ You'll want a specific folder to store the user-pictures; you don't want to store them between "all other" pics like logo's and the like. This gives also the advantage that you can delete everything in this path and rebuild it with the info from the database, without touching other graphics.
Bastard Programmer from Hell :suss:
-
The problem I have with that is if someone replaces a file with one you don't expect.
-
I'm working on a WPF app that has user profiles. The profile contains the user's picture. Any reason not to store the image in the Profiles table? Never done this before. Suggestions/comments appreciated. Thanks
Everything makes sense in someone's mind
-
PIEBALDconsult wrote:
The problem I have with that is if someone replaces a file with one you don't expect.
What does that have to do with how they are stored?
The file system is less secure.
-
The file system is less secure.
PIEBALDconsult wrote:
The file system is less secure.
I doubt that is relevant in a system that needs to be secure. If one does nothing but assume that a database is "more" secure than a file system with no other concern for security then they will have problems. And one a real security policy in place any real differences in implementation of systems at this level becomes much less significant allowing one the freedom to base decisions on other business needs.
-
PIEBALDconsult wrote:
The file system is less secure.
I doubt that is relevant in a system that needs to be secure. If one does nothing but assume that a database is "more" secure than a file system with no other concern for security then they will have problems. And one a real security policy in place any real differences in implementation of systems at this level becomes much less significant allowing one the freedom to base decisions on other business needs.
I'll stick with the more secure solution regardless. It's like putting things in a bank vault rather than relying solely on the security guard at the door.
-
I'll stick with the more secure solution regardless. It's like putting things in a bank vault rather than relying solely on the security guard at the door.
PIEBALDconsult wrote:
I'll stick with the more secure solution regardless. It's like putting things in a bank vault rather than relying solely on the security guard at the door.
Not at all. At least not at most banks, because your analogy is not a complete statement of the security policy in place at the bank. For instance...how is the vault secure if the door to it is left open, the front door to the bank is left open and there is no active security monitoring system in place? And note that several years ago one large study found that 90% of security problems with actual losses originated internally within the company.
-
PIEBALDconsult wrote:
I'll stick with the more secure solution regardless. It's like putting things in a bank vault rather than relying solely on the security guard at the door.
Not at all. At least not at most banks, because your analogy is not a complete statement of the security policy in place at the bank. For instance...how is the vault secure if the door to it is left open, the front door to the bank is left open and there is no active security monitoring system in place? And note that several years ago one large study found that 90% of security problems with actual losses originated internally within the company.
jschell wrote:
originated internally within the company.
Which is my point too. Generally, more people have access to the file system than to the database. A no-longer-gruntled sys admin could replace individual files, but not alter the contents of the database.