Load List Values for Improved Efficiency

An anonymous reader writes "Reduce the number of database hits and improve your Web application's efficiency when you load common shared list values only once. In this code-filled article, learn to load the values for drop-down lists when your Web application starts and then to share these loaded list values among all the users of your application."

Comments

Re:You know what's great

[tomhudson]

No.

A database is not the be-all or end-all of computing; however, it is the be-all and end-all of data storage and access when things such as consistency, concurrency, and recoverability are at issue.

For the types of lists mentioned in the article, simple files are easier to maintain in a consistent state than as data in a database.

Ditto for concurrency.

Why? Because of the lowered overhead, and because you can restrict write access to the whole file at the filesystem level, rather than an individual record. "chmod go-w". Problem solved.

Also, backing up and restoring is also simplified. No locking of records needed, etc.

Simple files are also MUCH easier to recover than a corrupt database. I've had to do both. Guess which one I prefer ...

If you take your example of codes in a file, how will you distribute it? How will you maintain it? How can multiple users access it? What happens if someone accidentally deletes it?

TFA was talking about serving lists through a web server. There is no "distribution". Its included dynamically in the generated page ... the only person who has direct access to it is the process running as the webserver.

Databases are designed to solve exactly these types of problems.

You need to have the One True Copy of the data, in all cases. If you wish to distribute a flat-file or marked up copy of that data provided it's completely static aside from a software revision, then that's fine. But keeping key data unprotected -- or worse, opening up yourself to multiple masters -- demonstrates to me that you're thinking about things at the hobby/toy project level, certainly not at a distributed or COTS level.

Again, you missed the point of the article - serving up a list persistently via a web server. Stuffing everything in a database in such a case is as inappropriate as making everything an object in C++ programming. It leads to a mess. the right tool for the right job ...

Your data is your application. It doesn't matter if the data is static or not. And for goodness sakes, if you're going to be using a database anyway for the dynamic data, eat the storage and keep the master copy in the freaking database!

First, your data is NOT your application. Your data is your data. Your application is your way of accessing that data. The same data can interact with multiple applications.

Also, its better to keep your master copy elsewhere than in the same place you're sticking your data. Otherwise, you have a single point of failure that will kill you.

(And if you're not using a database at all, well, that's further evidence to me that you're thinking at the toy/hobby level of project scope.)

Again, you seem to have totally missed the point of the article ... and my reply in context. But you also seem to have missed a bit of history - the first databases were not much more than hierarchial file systems. The concept still holds value today ...

Again (for the nth time), the right tool for the right job.