On Aug 20, 2008, at 7:11 AM, Alex wrote:
> Can I ask why you wouldn't query the database SELECT * FROM mytable
> name='test' *?
This can be a valid solution, too. Whether it is the *best* solution
depends on your application.
If you already had a vector of records from a previous query and knew
your target record was among them, you'd want to use the STL find()
algorithm on it to pick it out instead of going back to the database
server to pull it.
If you didn't already have the record you want in memory, asking the
database server to find it for you is superior, relative to pulling
the contents of the table and searching it in memory.
So much for simple cases.
Sometimes you can't express your search criteria in SQL. In that
case, you need to do the search in C++. Maybe you want to pull the
entire table, or maybe you can express *part* of the criteria in SQL,
and filter the subset down in C++.
Maybe the table is small enough that it fits easily into RAM and your
application is such that you don't need to worry about the table on
disk changing out from under your program. In that case, you might
pull a copy of the table early in your program's execution time and
run all of your queries against that using C++ code, because that will
be far faster than going over an IPC channel to the database server
and making it search files on disk each time.
Software engineering is all about trading off development time, run
time, complexity, maintainability, space, and correctness against each
other. You can't have everything, so you decide what you want most.
There is no single "right answer." It always depends on the
situation. That's what makes this engineering, and not physics or