http://thinkinginsideabiggerbox.disqus.com/enThu, 19 Oct 2006 14:16:15 -0000http://www.brodwall.com/johannes/blog/2006/10/18/on-integration-why-i-enjoy-working-with-databases/#comment-1797024Too bad about you losing you comment. I hate it when that happens.<br><br>The issues you take up are important, and I will let the feedback decide what I write about next. Specifically:<br><br>* I say: "The world is flat". You say "a large flat world is confusing". This is true. The world should not be flat, but from certain viewpoints, it should appear flat. I'll talk more about this later. This is how I want to address complexity and coupling.<br><br>* I had not originally thought about writing about triggering business functionality, but I'll incude our current work on this in a future post. (This was actually what triggered the whole Single Database Vision idea for me) And, like you, I am not a proponent of Stored proceduresJohannes BrodwallThu, 19 Oct 2006 14:16:15 -0000http://www.brodwall.com/johannes/blog/2006/10/18/on-integration-why-i-enjoy-working-with-databases/#comment-1797023puh! I had written a long comment to this post and then suddenly the math failed and I lost mye whole comment... so this will be some kind of sum up:<br><br>first I would like to say that I really enjoy reading your blog, exiting and insightful ideas that seems to be based on many many years of experience. really worth listen to!<br><br>but I really cant wait for the "how"-part of this serie, so here are some questions:<br><br>-how is it possible to trigger a business function in another application using your shared database strategy? I guess that all applications have access to all the data in the database, but what if an application A want another application B to do some calculations on a specific set of data. how do application A trigger this calculcation in app B? (I presume that you want to avoid the nightmare of stored procedures)<br><br>-how can you avoid that the applications get tight coupled? when the apps share and communicate trough a shared database then they have to know and use the inner data structures of the other applications. this will make them strongly coupled. if you change the structures of one application this might affect three others... isnt this like really entering the world of spaghetti?<br><br>-will it not be hard to change the technology that one of these applications are based upon? when the database layer are merged together and there are no explicit system borders in the database layers, how can you manage to replace the technology... isnt the system borders in a database just to vague and implicit? isnt it much better to move the system borders for instance up in a service layer?<br><br>my philosophy is that applications that solves different problems and that actually explicitly are separate applications should (if they have to communicate at all) know as little about each other as absolutely possible! and I dont see how you achieve this goal with the shared database strategy!chwlundThu, 19 Oct 2006 13:38:00 -0000