Depends
First of all let me say that the comments you've gotten so far don't even take the important factors into account.
I'm sure you'll get several posts about how naughty it is to use blobs in a database, but from a simplicity point of view, just uploading a bunch of text files and pointing to them via the database is easier and faster than loading same material into a blob field.
On the surface, if you want to use the blob fields, then you must tediously edit each blob field by hand in myphpadmin to upload the text file to the blob, or you must get a bit swanky and write a program that converts files to mysqldump format so you can load the whole db via phpmyadmin, or you must write a script to load the files from a dir on the host machine. Any way you choose is more work than ftp'ing those dogies into a directory.
Or you could create the html files in a WYSIWYG editor then just copy and paste the HTML. However these are books, there shouldn't be a whole lot of funky formatting which makes this much easier then if it were a magazine of some such. Also you get into file maintenence which is difficult to properly perform. There are more points on this but I'm saving them for reply to the other poster.
Here's a revolutionary idea how about writing a script to convert the text files into mysql database format.
I do think however that if you were to write a generic container application that the creation of a book in flat file php would be far more prefferable because mysql query's are far to overused within the industrys and much slower and less versitile than a properley constructed flat file database.!!!!!
First of all relational databases were created because text file databases couldn't do the job. Second of all you ever try searching a bunch of text files. Thirdly file mantenence is a nightmare. Fourthly, php has to have write permissions on a directory to accomplish this and that's a bad idea from a security perspective. Fifthly you can no longer rely on built in data validation or data functions in the database to accomplish certain things. Sixly you either have to write a sql parser or come up with your own query language to accomplish this properly.
Now remember that I did say it depends right so I'll go over the decisions here.
1) How fast is your database connection?
If your database connection is fast then retriving large amounts of text from the database shouldn't be that time consuming. On the other hand if your database connection is slow you will not want to return large amount of data in a query.
2) How is searching to be accomplished if at all?
If you're not going to allow searching of any type then this is not a consideration. However, if you are going to allow searching then you have to decide on how you're gong to allow searching now. If you're only going to search by author, title and topic then it doesn't matter if the text is in the database or not. If you're going to allow searching on content then you'll want the content in the database.
3) What's your development time?
If you want this done fast then you'll probably be wanting to go with downloading some open source stuff and modifying it. In this case find the system you want to use and then use whatever structure they have set in place.
4) Are you ever going to move this?
If the answer to this is not an immediate no then you'll need to think about the simplicity of this project. It's much easier to duplicate a database structure and populate it then it is to set up a file system and a bunch of files with ftp. Just make sure you write a dump/restore script and then if you ever have to move the site, just take a dump and restore it to the new database and all the data is on the new site in about a minute.
5) How much diskspace vs. database space does your hosting company allow?
Some companies allow more database space then file space. If this is the case you'll probably want to go directly with the database storage.
There are other factors too, but these are the main ones.
