dbAustin Case Study

Providing web and database services
to the Austin metropolitan area.

Database Austin Case Study – Local Austin Laboratory (page 3)

Design Decisions

Browser-based LAN database Application versus Native Windows Application

The first design decision was was whether to upgrade the database to a browser-based application or a native Windows application.

A Browser-Based Application uses an HTML browser (such as Internet Explorer or Firefox) on the client's machine to communicate with an HTML server computer. The server computer (usually) contains the database and the software to access the database and provide information to the user. This is in contrast to non-browser-based applications. These are the more traditional Windows applications that are compiled from a source code library and installed on individual machines.

The following chart shows the trade-offs considered in this decision:

Browser-Based

Non-Browser-Based

User-Interface

Generally uses standard navigation (hyperlinks and buttons), standard data entry (text boxes, drop-down lists, radio buttons), high level of user-fluency

Varies from application to application.

Maintainability

Generally uses scripting languages (ASP/VBA, Perl, PHP) and allows very rapid turn-around (sometimes minutes)

Generally compiled; fixes and enhancements are usually batched together because the release process is involved and time consuming.

Performance

Generally no performance concerns for most database applications (considered shallow applications)

Offers better performance for computationally intensive applications (such as engineering analysis). Little performance advantage in standard database scenarios.

Code Development

Personal experience has shown browser-based code development to be at least twice as fast as traditional compiled code development. The user interface is standardized and simple, and most of it is already present in the browser.

Compatibility

The server will have specific requirements based on the technology that is selected. However, the client (users') computers can be anything that supports an HTML browser (Windows, Linux, Apple, etc)

Generally restricted to a certain operating system, and sometimes only certain versions of the operating system.

Releases and Updates

Very simple: updated scripts are posted to the server and immediately seen by all clients

Complicated: distribution, dll compatiblity (also known as dll hell), level management, and packaging are all serious issues.

Source Code

Since the source code is interpreted on the server, the code on the server always represents the release level. You will not have to hunt down the source code.

Source code is compiled into an executable. Configuration management utilities are usually used to associate source code with releases. Sometimes the source code gets lots in antiquity, and a large asset is lost.

Next ->More Design Decisions

go to page 1 2 3 4 5 6 7 8 9 10

home

For more information, please contact
(c) 2007 by Database Austin

	Browser-Based	Non-Browser-Based
User-Interface	Generally uses standard navigation (hyperlinks and buttons), standard data entry (text boxes, drop-down lists, radio buttons), high level of user-fluency	Varies from application to application.
Maintainability	Generally uses scripting languages (ASP/VBA, Perl, PHP) and allows very rapid turn-around (sometimes minutes)	Generally compiled; fixes and enhancements are usually batched together because the release process is involved and time consuming.
Performance	Generally no performance concerns for most database applications (considered shallow applications)	Offers better performance for computationally intensive applications (such as engineering analysis). Little performance advantage in standard database scenarios.
Code Development	Personal experience has shown browser-based code development to be at least twice as fast as traditional compiled code development. The user interface is standardized and simple, and most of it is already present in the browser.
Compatibility	The server will have specific requirements based on the technology that is selected. However, the client (users') computers can be anything that supports an HTML browser (Windows, Linux, Apple, etc)	Generally restricted to a certain operating system, and sometimes only certain versions of the operating system.
Releases and Updates	Very simple: updated scripts are posted to the server and immediately seen by all clients	Complicated: distribution, dll compatiblity (also known as dll hell), level management, and packaging are all serious issues.
Source Code	Since the source code is interpreted on the server, the code on the server always represents the release level. You will not have to hunt down the source code.	Source code is compiled into an executable. Configuration management utilities are usually used to associate source code with releases. Sometimes the source code gets lots in antiquity, and a large asset is lost.