|
There are few questions that you should have answer to make this decision:
File System:
- Images sizes are smaller than 2 MB.
- No editing required on the images in future
- Faster access
Database:
- Image size is on a higher side 2+ MB.
- Easy maintenance and backup required
There is an another approach of FILESTREAM if you are planning to use sql server 2008.
http://msdn.microsoft.com/en-us/library/cc716724.aspx[^]
hope it helps.
|
|
|
|
|
|
I just read your article. Interesting so basically all that gets stored in the database is a GUID and correct me if I'm wrong a Hash of the file size? And the file itself goes in the file system? I don't see the benefit in storing the info 2 times. Other than maybe so it can be strongly typed.
Maybe I missed the Point I will reread the article
Frazzle the name say's it all
|
|
|
|
|
One of the main points is the transactionality. In case of an error you don't have to worry if the database contains a path to a non existent file or vice versa.
Second thing, backups. When you backup the database you also backup the files. No separate backups.
Thirdly, speed with larger files compared to storing all the binary info inside the database.
And the fourth thing, which I haven't covered very much yet is that you can actually stream the file better to the client when fetching.
I think those would be the main points. All comments are very welcome 
|
|
|
|
|
Mika Wendelius wrote: One of the main points is the transactionality. In case of an error you don't have to worry if the database contains a path to a non existent file or vice versa.
So it wil be Strongly Typed" This I like!
Mika Wendelius wrote: Second thing, backups. When you backup the database you also backup the files. No separate backups.
This I like Alot!
Mika Wendelius wrote: Thirdly, speed with larger files compared to storing all the binary info inside the database.
This should not be a problem, because I Intend to re-size the Images.
Mika Wendelius wrote: And the fourth thing, which I haven't covered very much yet is that you can actually stream the file better to the client when fetching.
This on the other hand I Love. But I will have to learn a bit more about. Looks like Google time!
Frazzle the name say's it all
|
|
|
|
|
WHich is more faster to compare values <> or != for performance tunning
thanks in advance
|
|
|
|
|
It makes no difference, both are the same.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
As said, from performance point of view, they are the same. However, since you didn't mention what database you're using, from syntax point of view there may be differences since not all of the databases understand both syntaxes.
|
|
|
|
|
we are using sql server 2008
|
|
|
|
|
SQL Server understands both the operators...no issue at all
|
|
|
|
|
RelationShip between to DataBase in SqlServer2008
this action in access down but sql I dont please help me.
|
|
|
|
|
First off get someone who has a better grasp of English to help you with your question b/c what you have written makes absolutely no sense (to me anyway).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
what you are trying to say ????
|
|
|
|
|
|
This should be fairly simple, but I'm rather new to SSIS.
I want to copy data from one table to another. The column names are not the same, and in the target table I may need to expand some columns so I don't get truncation errors.
I'm not really sure what objects in SSIS to use.
Many thanks
Everything makes sense in someone's mind
|
|
|
|
|
If the copy operation is quite simple, try following:
- define a Data Flow task and open it
- using Source Assistant, define the source database
- using Destination Assistant, define the destination database
- configure the source table for OLE DB Source (double click it to open the confiiguration)
- do the same for OLE DB Destination
- if you need expressions, add a Derived Column
- configure the derived column; add necessary new derived columns, their expressions etc
- connect the source to the derived column
- connect the derived column to destination
- in OLE DB Destination configure the mappings
Hope this gets you started 
|
|
|
|
|
|
I was thinking, can Microsoft SQL Server handle projects such as Facebook, Linkedin, etc? and if answer is Yes, then why they didn't go for it?
|
|
|
|
|
Don't quite understand the question. Those examples you gave are applications consisting of several different layers etc.
If you mean that could Sql Server serve as the back-end for the data, why not? Sql Server is capable of data distribution between several server, workload balancing, distributed transactions etc. so I see no direct reason why it couldn't handle the data.
|
|
|
|
|
It can handle the data and workload, its just that these online companies and startups (as they were) opted for the cheapest option (ie free) back when they started up, to minimise startup costs. They carry on using these systems as it will be too costly to migrate onto another platform.
Simple economics really..
JC
|
|
|
|
|
Yes, from the economics point of view the situation is different. For example Oracle has quite good concept now when MySql can be used when starting up and when performance etc problems arise, you can migrate to Oracle with a bit less work than to other database flavors.
|
|
|
|
|
Services like Facebook etc. need to be massively parallel and fault tolerant, to get the same level of service from sql server would mean a heavy investment in licenses, also these sites are using unix servers and sql server is not supported on them.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
|
|
|
|
|
The simple answer is, yes, SQL Server can handle the volume of data these sites catered for. The key thing to note about these sites, though, is that they tend to opt for NoSQL[^] databases - which is not what SQL Server is designed to do.
|
|
|
|
|
As said before, it's a financial decision. The Amaren[^] Nuclear Plant, and MacLaren[^] are using Sql Server. To be fair; they're doing something more complex than putting some html-pages in there
Bastard Programmer from Hell 
|
|
|
|
|
And I'm betting they have a serious investment in SQL Server licences. And they will almost certainly have had direct support from MS if they are pushing the edge of the tech. I know we were offered all sorts of incentives to use MS high volume framework including direct intervention from MS techs. Mind you the licences were $1m+.
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
