Mo wrote:
> On Jun 13, 3:46 pm, "Paul Lautman" <paul.laut...@btinternet.com>
> wrote:
>> Mo wrote:
>>> On Jun 13, 2:40 pm, Michael Fesser <neti...@gmx.de> wrote:
>>>> .oO(Mo)
>>>>> On Jun 13, 12:27 pm, Michael Fesser <neti...@gmx.de> wrote:
>>>>>> .oO(Mo)
>>>>>>> I thought that this was going to be super easy (and it probably
>>>>>>> is), but I couldn't figure it out.
>>>>>>> I have results from a MySQL query which include PartNumber, Qty,
>>>>>>> Cost, and Price.
>>>>>>> In one part of the report, I want to only display Sum/Total info.
>>>>>>> As an example, let's say there are 5 rows of data, and I want to
>>>>>>> know only the sum total of $result["qty"] from all 5 rows.
>>>>>>> I was expecting to use array_sum(), but have come to discover
>>>>>>> that this only sums all the elements of a single array.
>>>>>>> Any pointers?
>>>>>> I would let the database do it. Who cares about a simple second
>>>>>> query to get the totals? I doubt that this would cause any
>>>>>> performance problem.
>>>>> There are two reasons why I want to do it in my report coding:
>>>>> 1) Some of these values are currently stored in the DB, but
>>>>> unfortunately, they cannot be depended upon to be accurate or up to
>>>>> date.
>>>> OK, but where does the report data come from? How can this data be
>>>> more accurate then the data in the DB?
>>>>> Until we can rebuild the code and eliminate those bugs, I'd like to
>>>>> be able to get reliable info.
>>>>> 2) It would be a good learning experience.
>>>> OK. This would probably mean to loop through the array with foreach
>>>> and sum up the values.
>>>>> You mentioned a second query.
>>>>> Is that your suggestion?
>>>> In this case - yes, most likely.
>>>>> Just run a whole new query instead of extracting the info from the
>>>>> existing dataset?
>>>> A new query isn't that expensive if the connection to the DB server
>>>> is already established. Looping through an array and doing the math
>>>> on your own also takes some time, while the DB can access all the
>>>> wanted records almost immediately and do the math with highly
>>>> optimized code.
>>>> It might even be possible to do it all in one query with some clever
>>>> GROUP BY or UNION clauses.
>>>>> Is there a more efficient way to do this?
>>>> I don't think you'll run into efficieny problems here. Personally I
>>>> just use what seems to be easiest and most simple solution. And if a
>>>> second query gets me the results I want quite instantly, then I just
>>>> do it.
>>>> Optimization comes later. It requires to profile the code in order to
>>>> find the real bottlenecks. Replacing a query with handwritten array
>>>> looping can be considered "premature optimization", because usually
>>>> the really time-consuming parts of the code are somewhere else.
>>>> Micha
>>> To answer everyones question about reliable query info from an
>>> unreliable DB, the detail info in the DB is reliable, but the "total"
>>> values are not.
>> DUH, you shouldn't be storing totals. These get calculated in the query when
>> you extract them. This is what everyone has been telling you.
>
> Heh, heh.
> I'm not tmart, but I'm tronng :-).
>
> I'll go look at it from that angle.
>
> ~Mo
>

Yea, for more help, try a newsgroup for your database. They can help
you a lot on proper database design as well as how to format your query.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================