When building an application from scratch, should I start with the object-oriented (OO) model or the entity-relationship (ER) model?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
You might want to try to observe the principle of delaying architectural decisions as long as possible. The thought goes, that you will know more in the future about your problem domain than you do right now - so, any decisions you make today are suspect.
Another good principle to pair this with might be to try to attempt the riskiest parts of your requirements first - the thought being that if you do the easy parts, then find that the risky parts move you in a different direction, you don't have to re-do the easy parts. Risky here meaning things you aren't sure how you should do them.
Given these two, and given that I often try to approach things from an OO perspective, you might try to start with an OO model of the riskiest parts of your application first, and implement a least possible amount of code that can work that satisfies the risky requirements. Then, begin expanding your OO model as needed to add functionality you are going to need. All the while, you can completely delay your decision on whether to use SQL or NoSQL or flatfiles or cloud storage or whatever ... and you may eventually find you don't want relational at all (obviating the need for an ER model).
The ER model dictates how the application's data will be persisted, and the OO model decides how that same data will be stored in memory, or while the application is running. So, Database schema design (ER model) and class stucture design (OO model) are related design considerations, and can usually even be thought about concurrently. In fact, if you are using an Object-relational mapping (ORM) tool, your ER model and your OO model may be one and the same. In other words, your classes (OO model) may be annotated in such a way that they, themselves, specify the ER model.
Before designing, though, make sure you have a very good idea of the actual requirements of the software, what it will be used for, how it will be used, and who will use it. Many developers start thinking about design decisions before they fully understand the needs to be addressed by the product, and end up with a design that is ill-suited for the true purpose of the application.