Timber,
1. It is certainly not true that changes to one tier will always affect the other.
Explanation from
test:
In a two tier system, a change to one tier need not necessarily affect the other tier. For example consider an Order Entry system where the users need to see transaction history for individual customers. A new screen can be developed to take data from the transaction tables and display it on the client. In this example, no changes are required on the server. Consider an alternate example where a stored procedure accessing data spread in multiple tables now queries a materialized view. No changes would be required to clients that call the stored procedure, as long as all input and output remains the same.
2. Also it is a common falacy to think that two tier systems have only one database. You could always have an Order Entry and Management application where OE is one database and OM is another database. While OE needs to be a synchronous process, OM often does not. In such examples, if the OM server comes down, it does not halt the OE system from accepting new orders.
Explanation from test:
Although it may be true in many cases, Client/Server architectures do not always represent single points of failure. With single database servers, of course if the server fails, clients may not be able to connect to the database. However in multi-database applications, if parts of the client or server fail, other parts of the system may still be accessible.
HTH.
