January 8, 2015 at 7:07 am
We are re-organizing our IT dept, moving off a mainframe system.
The Applications area is moving to design applications based on SOA, in particular
following Udi Dahan’s concepts. My understanding is this has recently been given
the term of MicroServices.
They feel the database design should closely follow their application development.
They are starting to educate the database staff on what their plan is (why going with Udi’s design verses an Entity based design). From what I understand to date, this would entail splitting up data we would normally group together, say something about a person(Entity) of SSN, name, birthdate, etc into their own tables.
They’ve brought up that maybe the pieces of a name should be split out since different pieces can change at different times(example a last name on marriages where the first name stays the same). They are talking about being very granular in what’s in a table. Only things that change together should be in the same table. I understand the concept, but that seems to really spread out the data that is common to an object, like a person. I have concerns with retrieval of data where you have to then bring data from multiple tables together for batch/bulk processing. You either have to do a lot of retrieval to all the individual tables to get all the info you need or the database area createsviews to bring this all together or choices similar to this. It seems you’d pay a high price on the retrieval of data, which in our business is what most of the database activity is.
I’ve tried looking around for some info on what people are doing with SOA and database design and
haven’t found too much info. Could you point me to some info that may exist, or give me some insight
into what you’re aware of that people are doing related to SOA design and how to design a database to
work best under a SOA concept?
There are pros/cons to everything. I just don’t see a lot of info saying people should sacrifice what may traditionally be considered good database design in order to fit a SOA model, but maybe people
are moving in that direction?
Thanks for any info/advice you have,
January 8, 2015 at 11:02 am
Service Oriented Architectures are great. No question.
But this idea that a persons name has to be broken into multiple tables because part of it might be updated independently from the rest... No, that doesn't make any sense. In fact, from what I've seen of most of the SOA projects I've worked on, that's not how services work. They're suggesting that there's going to be a service called FirstName and a service called LastName and that these services will have separated code, separated storage and relationships between them will be defined... somehow? No. It's a Person service and there's a Rename action in the service. The storage would be in a Person table with a first and last name.
It really sounds like someone is seriously misreading things.
When it comes to data storage, the first question I would ask is, do we need structured or unstructured data? If it's unstructured, we shouldn't be in SQL Server. We should be looking at some kind of ID/Value database. We need structured storage? OK. Then, relational rules still apply, just as they always have. Nothing changes just because we're supporting a service. Now, you could be looking at splitting up your databases a little more than you used to since maintaining the code of a service and the data structures behind it needs to be isolated from other services. And, you may be seeing the use of GUIDs (just an example) for a primary key or an alternate key in order to better support the service. All fine and can be dealt with.
But what you're describing is not a normal part of Service Oriented Architecture that I've ever seen.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 8, 2015 at 11:20 am
I also recognize that some guy responding to your question on the internet is not going to be exactly compelling evidence on your side. So, I did a quick search to see what's out there in terms of documentation. Service Oriented Architecture, as a concept, is "old" (in computer years), so there's a lot of information. Funny enough, one of the first hits I got was an article on SOA and SQL Server written back in 2006. It doesn't get into specific table design, but the architecture and discussion around the architecture doesn't break stuff down into things so granular as LastName services.
Here's an article on SOA and database architecture. It shows the kinds of things I've seen a lot more than incredibly granular tables. It's showing a fairly wide table that I would naturally look to normalize if it were mine.
Interesting blog post on SOA and normalization. I can get behind it too.
I'm sure there are more out there.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply