Skip to main content
performance for multi block sized files
Source Link
user953
user953

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that's not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

A last, big surprise, the performance of a dbfs filesystem is often better than a regular filesystem. This is especially true if the files are larger than a few blocks.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that's not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that's not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

A last, big surprise, the performance of a dbfs filesystem is often better than a regular filesystem. This is especially true if the files are larger than a few blocks.

about backups and read only
Source Link
user953
user953

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that's not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

Sometimes size is given as a reason not to store documents in the database. That data probably has to be backed up any way so that's not a good reason not to store in the database. Especially in a situation where old documents are to be considered read only, it is easy to make big parts of the database read only. In that case, those parts of the database no longer have a need for a high frequent backup.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

added about refs and tx
Source Link
user953
user953

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

If going for oracle, take a look at dbfs and Secure Files.

Secure Files says it all, keep ALL your data safe in the database. It is organized in lobs. Secure Files is a modernized version of lobs, that should be activated.

dbfs is a filesystem in the database. You can mount it similar like a network filesystem, on a Linux host. It is real powerful. See blog It also has a lot of options to tune to your specific needs. Being a dba, given a filesystem (based in the database, mounted on Linux), I created an Oracle Database on it without any problems. (a database, stored in a ... database). Not that this would be very useful but it does show the power.

More advantages are: availability, backup, recovery, all read consistent with the other relational data.

A reference in a table to something outside the database is unsafe. It can be manipulated, is hard to check and can easily get lost. How about transactions? The database offers solutions for all these issues. With Oracle DBFS you can give your docs to non database applications and they wouldn't even know they are poking in a database.

typo
Source Link
user953
user953
Loading
Source Link
user953
user953
Loading