Thread: Math Operations - DB or App?
i'm in the process of developing some reports for an application i'm developing. i'm curious how the more experienced developers do their math operations. do you do it in your select or do you do it in your app? i can't give an example within a select (that's what i'm researching next). an example of doing the math in the app (php) would be getting a value $p for number of passed units and a value $t for total units and then setting yield to $y = $t/$p. what do you do and why? what are the pluses and minuses of each approach? as always, tia... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 5/9/06 3:44 PM, "operationsengineer1@yahoo.com" <operationsengineer1@yahoo.com> wrote: > i'm in the process of developing some reports for an > application i'm developing. > > i'm curious how the more experienced developers do > their math operations. do you do it in your select or > do you do it in your app? > > i can't give an example within a select (that's what > i'm researching next). > > an example of doing the math in the app (php) would be > getting a value $p for number of passed units and a > value $t for total units and then setting yield to $y > = $t/$p. > > what do you do and why? what are the pluses and > minuses of each approach? The biggest plus is that most of the data never leaves the server, so client-side overhead, memory issues with the client, and network bandwidth are much less of a problem than it you transfer the who table to the client, for example, to do a couple of simple sums. There are other advantages, like being able to adjust the schema or the functions on the database side and have these changes propagate automatically through to various apps. Sean
On 5/10/06, Sean Davis <sdavis2@mail.nih.gov> wrote: > The biggest plus is that most of the data never leaves the server, so > client-side overhead, memory issues with the client, and network bandwidth > are much less of a problem than it you transfer the who table to the client, > for example, to do a couple of simple sums. There are other advantages, > like being able to adjust the schema or the functions on the database side > and have these changes propagate automatically through to various apps. With which operations/what number of calculations does the CPU load on the server become a problem, though (compared to the network-traffic caused by having it on the client-side)? I can think of a few applications/implementations that I wouldn't want to be running on the server - where to draw the line? Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
On 5/9/06 5:37 PM, "Andrej Ricnik-Bay" <andrej.groups@gmail.com> wrote: > On 5/10/06, Sean Davis <sdavis2@mail.nih.gov> wrote: > >> The biggest plus is that most of the data never leaves the server, so >> client-side overhead, memory issues with the client, and network bandwidth >> are much less of a problem than it you transfer the who table to the client, >> for example, to do a couple of simple sums. There are other advantages, >> like being able to adjust the schema or the functions on the database side >> and have these changes propagate automatically through to various apps. > With which operations/what number of calculations does > the CPU load on the server become a problem, though (compared > to the network-traffic caused by having it on the client-side)? I can > think of a few applications/implementations that I wouldn't want to > be running on the server - where to draw the line? I would imagine that the answer is very complicated. There are a lot of details in application design that are being ignored by my answer above. For example, can data be cached effectively on the client side (or in a web app, on the webserver)? Is the app DB intensive (lots of concurrent read/writes) or are there monstrous queries running on the DB all the time (data mining app, for example)? There are many points that do and should influence application design, so benchmarking, knowing user needs, hardware and software constraints, and maintainability all play into the answer, I think. Not an answer, I know.... Sean
On 5/10/06, Sean Davis <sdavis2@mail.nih.gov> wrote: > > With which operations/what number of calculations does > > the CPU load on the server become a problem, though (compared > > to the network-traffic caused by having it on the client-side)? I can > > think of a few applications/implementations that I wouldn't want to > > be running on the server - where to draw the line? > I would imagine that the answer is very complicated. There are a lot of > details in application design that are being ignored by my answer above. > For example, can data be cached effectively on the client side (or in a web > app, on the webserver)? Is the app DB intensive (lots of concurrent > read/writes) or are there monstrous queries running on the DB all the time > (data mining app, for example)? There are many points that do and should > influence application design, so benchmarking, knowing user needs, hardware > and software constraints, and maintainability all play into the answer, I > think. > > Not an answer, I know.... I wouldn't say that :} ... it's pretty much exactly what I was hoping for, namely that there *IS* no answer, and that it always depends on varied factors which need to be evaluated for each individual case. > Sean Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
> I wouldn't say that :} ... it's pretty much exactly > what I was hoping for, > namely that there *IS* no answer, and that it always > depends on varied > factors which need to be evaluated for each > individual case. you mean there is no simple answer? -lol- my question is answered given my case. i can do it either way w/o noticable penalty. i'll probably do it in PGSQL b/c it means i will learn more new SQL/PGSQL techniques. not simple... but fairly effective. so far, anyway... ;-) thanks for the insights. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com