I’m just reading the book here: http://www.amazon.com/Java-Architects-Handbook-Second-Edition/dp/0972954880/ trying to find a strategy about how to efficiently design a (generic) medium to large application (200 tables or more) – for instance a classic, multi-layered, corporate intranet. I’m trying to adapt my past experience (as a database designer, but also OOAD) in order to architect such a java application. From what I’ve read, if you define your entities first, there is no recommended way to infer your database directly (automatically).
The book says that you would build the entity/object model first (OOAD) and THEN there is the db admin/dev.(?) job to build/infer the database (schema, normalization etc.) based on the entity model already built. If this is the case, I’m afraid the architect/developer could lose control over important aspects – normalization, entity-attribute-value modeling etc.
Perhaps like many older developers (back-end developers, architects etc) I feel more comfortable defining the database schema first – and spending a good amount of time on aspects like normalization etc. While this would be certainly possible nowadays, I’m asking myself if this would become (pretty soon, if not already) the ‘old fashioned way’ and not the norm – as a classic/recommended approach when designing applications from scratch.
I know Entity Framework (.NET) already have these approaches explicitly defined – ‘entities first’, ‘database first’, ‘code first’ and and these could be mixed, if necessary. I surely know that they recommend ‘entity first’ for newly designed apps, and ‘database first’ if you have already defined database schema (which is the case for many older applications, when migrating etc. I’m just asking if there is something similar for the java world.
So, the questions are: (although I know there is no silver bullet etc.)
- ‘Entities first’ for newly built apps – this is the norm nowadays?
- What tools do you use (if any) in order to assist inferring db schema process? – your experience, pros & cons with concrete UML
- What if you have parts/older/sub-domain database schema (which you’d want to preserve, mainly)? In such case, you would infer entities model from
database and then refactor the model using your preferred UML tool?
- From labor force perspective (let’s say for db of 200-500 tables): what is the best approach: for instance, to have 2 different people
involved in designing OOAD/entities and database respectively,
working together with an architect?