3

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.)

  1. 'Entities first' for newly built apps - this is the norm nowadays?
  2. What tools do you use (if any) in order to assist inferring db schema process? - your experience, pros & cons with concrete UML tools etc.
  3. 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?
  4. 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?
Mihail Stanculescu
  • 129
  • 1
  • 7
  • 1
    You 2nd point is clearly off-topic. In general I think it's much too broad. You can write books about such design principles. Lookup wiki for ICONIX. That once helped me a lot. – qwerty_so Jul 23 '15 at 11:58

3 Answers3

4

As you expect - my answer is it depends.

The problem is that there are so many possible flavours and dimensions to a good design you really need to take the widest view possible first.

Ask yourself some of the big questions:

Where is the core of the system? Is the database really the core or is it actually just a persistence layer for the code. It could also perhaps be that the database is the core and the code is really just a snazzy UI on the data. There can also be a mix - where some of the tables are core along with some of the entities.

What do you see in the future? Remember that there are developments going on as we speak that are moving database technology rapidly forward. There are some databases that are all in-ram. Some are designed for a distributed architecture. Some are primarily cloud. If you build your schema first you risk locking yourself in to a certain technology.

What scale do you want to achieve? By insisting on a specific database you may be closing doors to perhaps hand-held presence.

I generally find entity first as the best initial approach because you can always derive a schema from the entities and some meta-data. It is certainly possible to go schema first and grow the entities out of the schema but that way you generally find the database influences the design too much.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • So essentially you say that the 'vendor/database dependency factor' is what weights the most. In my case (although these are questions for a generic java app) - I think the entity model is the most valuable. Let's take the case of a healthcare app. - you essentially spend valuable time trying to model a complex reality, a model you want to persist for many years; but also want it to be modified easily enough (EAV modeling is a classic approach, with pros & cons). In that case, I understand you'd choose to concentrate on entity modeling first (DDD, fat or anemic etc.) – Mihail Stanculescu Jul 23 '15 at 10:47
  • 1
    The term "entity" might lead you astray: you probably want to ensure that the domain, the conceptual core of your application is built such that you can use it with whatever GUI or persistence layer you think is right. If you are just building a very, very thin icing on the cake -database-, you could probably start with the persistence layer, otherwise concentrate on the core layer first. Note that the problem you are thinking about is quite typical for object-to-relational mappings (the so-called "impediance mismatch"). You might want to think about other persistence options, if possible, – schaueho Jul 23 '15 at 12:57
  • That's right. In fact, one could rephrase such this: while doing entity modeling, you primarily think in terms of OOP/OOAD concepts; conversely, if you plan database first, you naturally think in terms of normal forms, E/R modeling etc. JPA/ORM designers try to lose up a bit this 'battle' (well known 'impedance mismatch'), but nevertheless you couldn't solely design a complex app. primarily respecting OOP/OOAD principle and ONLY with normalization IN MIND. Such schemas could go easily up to hundreds of tables/entities. A good db design is a religious thing for many seasoned designers. – Mihail Stanculescu Jul 23 '15 at 14:16
2

1) I've done database first in the past but now I usually do Entity first but that's mainly because of the tools I'm using in creating the applications. Entity first has a few good advantages over trying to match your entities to your defined schema later. You're also not locking yourself to tightly to your schema. What your application is for matters alot as well, if it's just a basic CRUD application, write once read many or does it actually 'do' something that will inform your choice over how to architect your application.

2) I use hibernate a lot which encourages creating your model first, designing all your entities etc and then generating the schema from that, hibernate can generate your whole schema from the models you've created (though you may need to tweak them to make sure they're not crazy). If you have 200 entities in your model then you probably want to do a significant amount of UML modelling ahead of time to ensure your model is consistent.

3) If you're working with partially legacy database then it can sometimes be good to fall into line with the schema design for that so your entities and schema are consistent. It can be a bit of a pain but then so it trying to explain why part of your app is just different to other parts. So yes I would probably infer my entities from the schema in that case. But again if it was totally crazy then it may be to do some very specific DAO code to hide that part of the schema from that app and pretend it's not there.

4) I can't really give you a good answer on this as I'm not sure what you're driving at really. Once you have the design standards for your schema it's turning the handle to crank it out.

So after all that my answer is 'It depends'

Andrew Aitken
  • 671
  • 3
  • 14
2

While the answers already posted cover a lot of points - and ultimately, all answers probably have to all sum up to "it depends" - I'd like to expand on a point that's been touched on already.

My focus is on data - I'm a business intelligence and data warehousing developer, and I deal with issues like data quality, data governance, having a set of master data, etc. To this end, I have to pull data from other systems - data which is in varying conditions.

When considering whether the core of your system is really the database or the front end (as suggested by OldCurmudgeon), I strongly suggest thinking outside of your own area. I have seen and heard about many systems where it's clear that the database has been treated as an afterthought (sometimes created via an entity-first model, but also sometimes hand-built), despite the fact that most of the business value is in the data. More and more companies are of course realising that their data is valuable and are adopting tools to make use of it - but it's difficult to do if poor transactional databases mean that data has been lost, was never saved in the first place, has been overwritten when a history is needed, or is inconsistent.

While I don't want to do myself and others with similar roles out of a job: If the data that a system you're working on is or might be valuable, if there's any reason it might be accessed by anything other than the front end you're creating, then it is worth the time and effort to create a sound data model to hold it. If the system is for an organisation or is going to be sold to organisations, there's a decent chance they'll want to report out of it, will want to run output from it into a data warehouse or other data stores, and will want to carry out analysis on the data it creates and holds.

I don't know enough about tools like Hibernate to know if it's possible to both use them to work in an entity-first manner and still create a good quality database, but I know that I have come across some problematic databases created in this manner. At the very least, as has been suggested, if you are going to work that way, make sure it is producing something sane and perhaps adjust it where necessary to maintain data integrity. If data integrity is a key requirement and you cannot get such a tool to create a suitable database that will ensure data integrity, then perhaps consider going back to doing things the "old fashioned" way.

I would also suggest that there's real value in developers working alongside any data specialists, analysts, architects, etc. they may have as colleagues to do some up-front modelling, even if the system they then produce uses entity-first and even if it veers away from the more conceptual models produced early on for technical reasons. I have seen many baked-in problems in systems which have been caused by a lack of understanding of the wider business entities and relationships, and which could have been avoided if time had been spent understanding the overall structure in this way. I've been personally responsible for building those problems when I was an application developer myself, so this shouldn't be read as criticism of front-end developers - just a vote in favour of cross-functional and collaborative analysis and modelling before development approaches and designs are decided.

Jo Douglass
  • 2,055
  • 1
  • 19
  • 30