2 ms·
Also, I didn't want to write to the database each time someone uploads an image. I just wanted to queue all these writes and do it at once in the end when a use
by amrithk 18y ago
Also, I didn't want to write to the database each time someone uploads an image. I just wanted to queue all these writes and do it at once in the end when a user commits to make all the changes.
That would save some processing time right? Thanks.
- gaius 18y agoWould it save processing time? Why do you think it would? How do you plan to manage the queue - by writing your own "database"? If you queue them somewhere, you'll end up having to do two writes, one to your queue and one eventually to the database. So that's adding more processing. 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.
- amrithk 18y agoSorry if I am not being clear. 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
- mechanical_fish 18y agoThat would save some processing time right? 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.
- amrithk 18y agoThat's helpful. Thanks. Maybe I am overthinking too much about optimization. It doesn't seem like updating a bunch of columns with text will result in significant time savings.