> It's been few days I'm following this conversation and I just wanted to > add something... It is true that both ways have their advantages and > disadvantages but do not forget that space is cheap now, data movement is > very easy but speed is costly. Improving one factor will affect the other > one negatively... so before taking a decision you should know which one to > sacrifice.
Very good point. I alluded to this in previous comments on this topic. An example is backing up the database. An essential part of the backup cycle for a database is a full dump. The more often you perform a full dump, the quicker you will get the database back up following a hardward failure. If you store only a reference (like a file name) of blob data instead of the data itself in the database, I think we can all agree that the size of the database will be dramatically smaller. The data files can be backed up separately and usually very efficiently since typically you add new files but infrequently update existing files. As you correctly suggest, the time required to restore a huge database containing blob data could become a limiting factor. We have databases in our installed customer base which take around 4 hours to load from a dump on the fastest hardware available, and we do not store any blob data in the database. If we did store blob data, the database would take days to load. Glenn Lawler ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
