> It seems to me as such a database gets larger, it will become much harder to manage with the 2 systems. I am
talkingmostly about music. So each song should not get too large.
I was just talking about points to consider in general. Getting to
your specific situation...
As far as BLOBs vs. file pointers. Test it out, use what you're most
comfortable using.
I would not set up a networked file system for the sole purpose of
managing and storing files a database will point to. If you already
have access to a networked file system, consider that as an option,
but don't add more work for yourself if you don't have to. Many
applications I work on use the database to store pathnames while the
files themselves are stored in a networked file system. It's honestly
not a huge pain to manage this if it's already available, but as I
mentioned before, there are caveats.
Also, in my experiences, the amount of management you do in a database
doesn't directly depending on the amount of data you put in. In other
words, your database shouldn't become much more difficult to manage
over time if all you are doing is adding more rows to tables.
> I have read alot on this list and on other resources and there seems to be leanings toward 1+0 raids for storage. It
seemsto the most flexible when it comes to speed, redundancy and recovery time. I do want my database to be fully
atomic. I think that is important as this database grows. Are my assumptions wrong?
>
As far as RAID levels go, RAID 10 is usually optimal for databases, so
your assumptions are correct. The extra cost for disks, I believe, is
paid off by the advantages you mentioned, at least for typical
database-related workloads. RAID 0 doesn't allow for any disaster
recovery, RAID 1 is ok as long as you can handle having only 2 disks
available, and RAID 5 and RAID 6 are just huge pains and terribly slow
for writes.
Note that you should go for a battery-backup if you use hardware RAID.
Hope this helps.
Peter