What I was saying was - everything slows down when it gets bigger. However, a lot of work has been put into database engines to keep them going fast even when they get big, whereas file systems slow down considerably when they get bigger.
It's not the storing of the link that's the issue. That's the easy part. It's the placing of the image file in a folder on a file system, or deleting it, or renaming it, that will slow down as the file system grows. For example - when systems grow busier - you get more and more situations where multiple people want to access the same image at the same moment. Databases have all kinds of mechanisms to regulate this. A file system may choke. Another example - when you move an image from one folder to another - you'll have to manually update its link. On a database - if an index is pointing to a BLOB and you move the BLOB around - the index will follow it around and continue to point to it. Again - a file system will be fine with a handful of users of a few thousand images. You won't notice anything. But, if and when the activity level rises you'll see it running into problems more and more. Hope this helps. > > [EMAIL PROTECTED] wrote: > > > Another perspective on the subject of BLOB vs. > > Links. > > > > > > Links are easier to implement and may be an OK way > > to start. However, a file system is really a crude > > database, and I emphasize "crude". It's not very > > good at handling high transaction rates, access from > > multiple machines, or volume. > > > > > > If your application grows quickly and before you > > know it you have hundreds of folders with thousands > > of files in each - your file system will slow to a > > crawl. All the performance, security, and > > consistancy features developers have worked so hard > > to put into database engines don't or barely exist > > in file systems. > > > > > > So - if you go the link approach - you'll be fine > > for a while, but when you see the directory > > structure starting to buckle - it might be time to > > give BLOBs another look. > > I'm confused. It sounds like you're basicallly saying > that databases slow down as they grow bigger. That's > logical. > > But then you suggest that, when a database begins to > get too big, BLOBs may be better than storing links. > > I don't understand that. How can storing images as > BLOBs be more efficient that creating a field that > simply stores links to those images? Or am I missing > something? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
