Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

true ro false about 2-tier architecture models

 
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Which of the following are NOT true about 2-tier architecture models?
1.Any change to one tier typically affects both tiers
2.Represents a single point of failure
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic