Monday, June 28, 2004

Client/Server vs. File/Server vs. ASP

There's a lot of Fear, Uncertainty and Deception (commonly known as FUD) in arguments that go through sales discussions with different vendors. Every company has staked their claim to a particular strategy (be it Client/Server, Java, Delphi, Linux, AS/400, Windows, SQL, Oracle,etc) and go through numerous steps to proclaim their approach is the best.
 
Performance is largely based on setup and usage. You could be driving the fastest car in the world but if you have to go through a tiny driveway, you have to slow down.
 
Every solution has its ideal target audience. MTI isn't going to try and sell a Windows-based solution to a company that has already made a huge investment in AS/400 unless they are ready to change. If you already have an Oracle database and people with detailed knowledge of your solution, asking you to switch to SQL Server or IBM's DB2 product doesn't make a whole lot of sense. What language a tool is written in is a similar argument. German has just as much validity as English as a spoken and written language. More people in North America just happen to speak English.
 
If you're still insistent on debating about individual platforms, consider the resources required to manage the solution. File/server based applications work just like basic Office applications. You run them on a shared drive. Either you have access to it or not. Client/Server applications require a stronger network infrastructure and someone with more knowledge about databases - a typical "network connection" guy won't usually cut it. If you've got your own IT resources, it certainly looks attractive but when things go wrong, you better make sure you have the right person to solve it - otherwise it can turn into a mess.
 
So there are pros and cons to each technology architecture. The functionality of the software is immaterial - how things get managed is critical. Hope this helps...
 
File/Server Based Applications
 - easy to move around and manage individual files
 - better performance by upgrading individual machines (desktops are typically cheaper than servers)
 - core applications located in one place (for easier updates) / runtime files on workstation
 - performance depends on optimization of individual machines and speed of network
 - corruption typically limited to few tables
 
Traditional Client/Server Architecture
 - client software installed on workstations that access data on a server
 - heavier server requirements (typically more expensive although fewer)
 - performance depends on optimization of server and speed of network.
 - invisible indexing and backup
 - corruption can be time-consuming and impacts entire database
 - stronger security access
 - client software upgrades often required on each workstation
 - often requires training of DBA (database administrator) resource on staff
 
Multi-Tier Client/Server Architecture
 - higher server requirements as business processing may be done on the server or the client
 - workstation client may be web or windows-based
 - updates typically only done on server / minimal updates required
 - ideal for hosted solutions
 - invisible indexing and backup
 - more places for possible disconnect between applications
 
 

0 Comments:

Post a Comment

<< Home