From: Warren Young
Date: August 21 2008 2:03am
Subject: Re: A way to copy mysqlpp::StoreQueryResult into a std::map?
List-Archive: http://lists.mysql.com/plusplus/7892
Message-Id: <95D1695C-0FF1-4B2C-A25A-EEC6B9E33C0B@etr-usa.com>
MIME-Version: 1.0 (Apple Message framework v928.1)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Aug 20, 2008, at 7:11 AM, Alex wrote:

> Can I ask why you wouldn't query the database  SELECT * FROM mytable  
> *WHERE
> 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  
mathematics.