One important facet of software design is the cardinality between items in your system design.
As an example, consider a simple credit card based design from telecommunications:
Given this design, you can explore many boundary conditions with your business partners.
- Can you have a customer without services?
- Can you have billing information without an account? How about the other way?
- I'm diagramed this as having multiple BillingInfo entities. Should they allow overlap? How about one time payments? Refunds and chargeback processing?
Getting into the details of how the business works will provide you a lot of leading conversations as you develop your system, but I want to focus just the one relationship in dark black above, specifically the qualitative dimensions of the 0 or more accounts.
If you think about a mass consumer product, you will have a fairly low cardinality of accounts. A wireless customer may have a family plan with multiple phones, perhaps high speed internet or a video product.
This can lead you to design a graphical interface assuming that you can display all of the accounts for a customer all of the time. Perhaps you can even bring up all of the accounts when searching for customer.
All is well. And then it happens, someone tries this same data access for a large bank. Think of the number of communication accounts they must have to support their business:
- Branch office numbers
- Main numbers
- And the real killer - every ATM they have everywhere
Now your getting thousands of accounts back for that one customer. Uh-Oh. If you have a document store like MongoDB, you are now getting megabytes of information. If you have a relational database store, you getting thousands of rows; depending on the fetch size you have configured, perhaps hundred of round trips to the database that you are not expecting to have to wait for.
The lesson to be learned here is that you need to know not only the 0, 1 and multiple basic cardinality of the relationships in your designs, but also the distribution of what "many" means.
Comments
Post a Comment