Why not store the multimedia in the filesystem?
When managing multimedia, the argument should now be, please justify why the files should be stored in the filesystem and not the database. There might be business cases for storing multimedia in the filesystem, especially if there are older applications and tools that need to access the files, but can only access a filesystem. As will be covered in Chapter 9, Understanding the Limitations of Oracle Products, there is a strong case for the use of the Oracle Database File System.
Only by using web services and integrating access into these tools to access the database can these restrictions be removed. It's possible to build programs that can be integrated into Windows File Explorer, Adobe Photoshop, Microsoft Word, and PowerPoint that can directly access the database and retrieve the files.
The following are some arguments why storing unstructured data in the filesystem might not be a good idea:
Security: Different operating systems have different types of filesystem security. Some are quite powerful but most offer basic course grain which cannot easily integrate with database security. If using Apache and all your images are in one directory, how do you configure it so that a user can access only a set of files, while another user can only access others? It can be done with a lot of effort and using specialized plugins, but it doesn't easily integrate with the database security and it's very hard to monitor, audit, integrate, and control. There is more likelihood of holes in the security being opened by trying to implement a tight security policy. Applying security to unstructured data stored in the database is so much easier.
Backup/recovery: Database backups are well known. The challenge is to try and ensure the filesystem backups are coordinated with the database.
Filesystem limitations: Most filesystems can only store 65,536 per directory. For a multimedia warehouse it's feasible to want to store millions of digital objects in one directory.
Performance: Filesystems are notoriously slow for accessing and managing. Put 10,000 digital objects in a Windows filesystem and try to use File Explorer to look at it. Try to mass rename or change the security on 20,000 digital objects. Try to do a search against a filesystem looking at all directories when the filesystem might contain a million or more digital objects. It's incredibly slow. In some cases it fails. Try highlighting 1,000 objects in File Explorer and moving them to another location. It's painfully slow and difficult to do. Digital objects stored in the database offer the ability to make changes to millions of objects in seconds. There is no real performance comparison. Searching for and manipulating objects in the database is much faster than trying to achieve the same in the operating system. Arguments might be made about load and retrieval times, but with the latest release of Oracle with Securefiles this argument doesn't hold much weight anymore.
