Database application architecture - High performance software

Database application architecture: How does a computer operate?

Why couldn't you get that message when you were at line 2? Because you had NO computing power on your desk: all programs were running on the central computer.

Today it is another situation: Your application architecture delivers more computing power on your desk than these old mainframes could ever dream of.

And still your system is slow, making you wait forever?

Most likely, it's because of the database application architechture.

When PC's came into play, the IT professionals soon found out that much of the work could be done on the client. The client is your PC, hooked up to a server (a computer far away). So the application architecture changed radically: The software engineers placed a lot of logic on the PC's to avoid putting a too heavy workload on the server(s).

That sounds right, yes? The problem was: Now the network had so much to do, sending all the traffic to your PC, that the network became the bottleneck.

Imagine you want to see all information on a specific customer: the server sends you all customers and tells your PC: You figure out for yourself which customer. That is exactly what happened in client-server computing. The result was very slow performance because of the enormous traffic over the network.

Today, we have a new appproach to this: We split the application architecture logic in different layers, and we minimize traffic. This is called multi-layered software; many people call it three-tier: The database server does its job, which is to find data, the application server acts as a middle man; getting data after receiving requests, and the client (your PC) does only functional computing; that is, allowing you to act upon, and manipulate, the data you get from the application server.

(Bear in mind that this section of the website is relatively new; There will be other topics added here in the future).

Microsoft SQL Server Training keynotes

• This keynote shows you the basic principle for designing real high-performance database applications, without having to think about the database itself.
• This keynote addresses issues regarding good and bad practices when designing a SQL Server Database. In this issue, we address good and bad practices for the Application Layer/Tier. The benefits of stored procedures are illustrated with code samples.
• In this keynote, special considerations are given to most flexible and best practices for reusing your code in a web application communicating with the SQL Server Database.
• This keynote deals with good practices towards MS SQL Server: SQL Server Programming communicating with the SQL Server Database.

Return to Database Design home