That would save some processing time right? Thanks.
If premature optimization is the root of all evil, I'm afraid you are halfway to hell.
This is not a good reason to make your app more complicated than it needs to be. For one thing, it isn't even easy to tell if your statement is true, let alone how true it is. (i.e. it may be true that you save a few milliseconds, but is that even going to be significant?)
If there is a UI reason why you have to have the user specify 25 uploads on one HTML page and then do them all at once, that's one thing. (I'd use the big-pile-of-hidden-HTML-fields approach; that has the fewest moving parts, it's simple to conceptualize, and I don't think the other methods will make a big difference from the user's perspective.) But don't try to work around your DB until you absolutely have to. Use it. That's what it's there for.
It's a serious question. Have you benchmarked this? Writing BLOB data to any reasonable database (or storing it as BFILE if you must) is imperceptibly slower than a filesystem write. In the case of MySQL the database is just syntactic sugar sprinkled on the filesystem. In the case of Oracle on raw volumes it's going to be faster to write to than a cooked filesystem. If you're worried about huge transactions, just COMMIT each one and add a column for approved_yn that you update in a single transaction when the user is happy.
I am not uploading each image as a BLOB. Rather, I am storing a bunch of strings in the database that will later help me point to the actual image (which is first stored in the local webserver but is pushed into Amazon S3 after the user has finished with the form).
I want to avoid these multiple writes to the database (which stores various pointers to the image) and just do one large write operation at the end. Does this not matter? Would you know any benchmarking tools that will help me measure this?
Thanks