Bonnie,

>>Rubbish, SQL servers are not capable of doing complex statistical analysis. If I want to calculate trendlines, scatter diagrams etc, IOW calculations with a lot of datapoints I need all data in an application that is capable of doing the statistical calculations. It requires the whole dataset to be downloaded to the client. The server side is responsible of getting me the data, the client side is responsible of processing that data into a form that has meaning to the users.

>I typically see the client-side as presenting the data to the users. The server-side can do more than just get the data from the database. The data can be processed server-side as well, prior to sending it to the client. This can be done with server-side code (not the SQL Server database itself). I see nothing wrong with this architectural view. If you disagree, then fine ... we disagree. Doesn't mean I'm wrong. Doesn't mean you are either.

Well look at BA software (Crystal, Holos) and statistical software (SPSS, Excell). They all require (in most cases) the full data to be present before doing their statistical work. This is a totally valid and proven working model. The complexity of the statistical/analysis process is them implemented in only one layer.

>No, you should not generate graphs server-side, but you can do the statistical analysis server-side and send the resulting data from that to the client to be presented to the user.

For simple statistic this might work, but in most cases, you would not do that. Sure you can use SQL to generate summaries, but that in itself is not the level of statistical analysis I'm talking about.

>>Client server does not mean that the client is on a different machine than the server. It is about different layers (in which the layers can be on the same machine).

>Yes, I'm fully aware that the layers *can* be on the same machine, but in a typical client-server application, the user is accessing data that is *not* on the same machine.

So you want to do the statistical number on the same machine or not. If not, what are you saying here. the data still has to the cross the network. If you do, you are hurting the server resources because of the statistical process you're doing. If you've have tried to generated hundreds of pages with multiple graphs on there (As I've done with calculation leave hours for tousands of employees), I can tell you don't want to do this on a server as it drags downs your resources dramatically. A database server, needs to serve data. Analytical processing should be done elsewhere.


>In anyway, you're not providing a solution for this specific case. A SQL server (yes the machine itself) should do concenrtate on providing data. Analysis of data should take place elsewhere or else your server performance is severely affected. In a traditional C/S setup that means the client machine.

>I disagree. Analysis of data can take place server-side without affecting the SQL Server's performance ... "server-side" does *not* necessarily mean you only have one machine there.

You missed the word "Traditional CS" this means, SQL server on the backend and GUI on the front-end, a 2 tier model. If you want n-tier, that might be another, but more complex solution as you might have to handle load balancing. The traditional CS approach is a more simple one as then you take advantage over the desktop processor.

>>Look downloading 50,000 row of 500 bytes a row, = 25 megs and takes about 3 seconds to download on a 100 mps network. Not a big deal... Why force the statiscal processing on a central server
>while you have so much processing power on your workstation ??
>
>Not everyone has powerful workstations.

Not every organisation has the horsepower/in house knowledge to do this on the serverside as well. Remember that you're centralising resource intensive procedures. If there are a lot of workstations which will concurrently ask for such analysis, you might be better of in offloading this to the client avoiding performance problems and resource hicups.

>>Bonnie, I appreciate that you have learned to solve problems in a certain way, but as I see it you have learned to work with limitations that are constrained by the tools at hand and totally forgot why you are solving problems the way you do. This is BAD. You should be open to find the ideal solution, and *if* constrained by the tool, hardware or infrastructure, you should know that.

>I'll say it again Walter ... the architecture that I have described is not a limitation of the tool, it is the generally accepted definition of client/server types of applications. If you disagree with that, then fine, you have the right to not agree with everything that I say ... we can agree to disagree.

In the describes case, you provided the correct answer, I agree. I disagree with the concept that downloading lots of data to the client should be avoided at all costs. It is not a black and white thing. Some type of applications, just might ask for doing this. Again many BA tools just ask for this type of processing. They seldomly are directly installed in par with the SQL server.

And even in non statistical applications, you might want to choose to download data in a whole batch, because the type of application asks for it. If the user on the average will make so many queries on the same data, but with slightly different aspects and the data is (almost)static in nature, you might be better off getting it at the client and process that data based on the users commands. It then would minimize the network trafic.

Walter,