Page History
...
- Designing a Distributed Database
This brings a new level of complexity to applications. What's on the client(s)? What's on the server(s)? How much disk space? What client/server model is to be used? Object Locking? - Designing a Distributed Application
What runs on the client(s)? What runs on the server(s)? What runs on both? What client/server model is to be used? - Performance and Communications Loads
How much load on the LAN? Can it run on twinax? What about slow leased line and dial-up access? - Security and Integrity Considerations
Backup what? Backup when? Backup where? Software distribution and upgrade procedures across "n" PCs? Security administration across "n" PCs? - The User Interface
What about OOD? GUI WIMP constructs? Action bar object-action designs? This is not a traditional IBM i "menu driven" system.
...
In summary, some client/server design dos and don'ts:
DON'T
- Start with a critical application.
- Design traditional NPT applications and try to run them on the client with all database access to the server database.
- Ignore resource loads until the end of the project.
DO
- Spend a lot of time on design.
- Do not design for NPTs (non-programmable terminals).
- Distribute data according to whether INQUIRE or TRANSACTION intensive.
- Estimate & test & validate that the resource loads can be handled before undertaking the project.
Data validation:
Selecting records from multiple files on the server:
Selecting a high volume of records on the server for calculations: