Reference no: EM131091809

For your current assumptions about the users, the functions that they want to accomplish, etc., what do you see as the most critical performance requirements you have to meet? Can you express that in either volumes of data, or numbers of users, for example? Or in terms of transactions (create/update/delete operations on data) per day, hour, minute, or second? Do transactions have to be processed in a specific maximum amount of time?

How do you see those user-level performance requirements translating into physical database design implementations? Does this drive you to consider simpler ways of structuring or representing the data or how you use the various kinds of keys? What about indexing?

Suppose your database project is a roaring success, and you scale it up big-time! (Example: you have been building a Bed & Breakfast reservations and management system, and now dozens of B&B operators all over your resort destination area want to cooperatively use it to manage bookings, referrals, billing, etc.) What "multipliers" would it take to stretch your system to the breaking point - much larger files, many more users, more transactions per unit time? How might you cope with those? At what point do you "outgrow Access?"

Consider the restrictions that a typical database project might need to impose, either on the way users use the system, the kinds of data they put into the system, or the constraints the system is expected to enforce "naturally" (as if it read their minds during the design phase). What are these? How do you allocate which restrictions to which part of the finished system (people, business process using the database, tables and relationships, other DBMS features, or?).

How might "massive multipliers" on demand for your system, such as in (3), affect your thoughts about which parts of the physical design to enforce the constraints you identify in (4)?