About how database web application development nowadays has gone absolutely and utterly absurd.
May 2008 - in Helsinki - a new approach for designing and implementing database web applications was presented. It was there and then declared to be "the only right way to build these kind of applications."
(New visitors: start here.)
Hi there, I just wanted to say thank you for this series. I'm a developer who started years ago as a DBA, and I've long had this thought that keeping "business logic" out of the DB was a bit of a crazy prejudice.
I've very much enjoyed finding out that there's someone else who has given a lot of thought to designing things a more sane way. This has been a great read, so has the trigger blog. A copy of your book will arrive at my house tomorrow, and I'm very much looking forward to reading it over the Christmas and New Year's holidays.
I hope you find time to finish this series at some point.
I guess this is as good a place to say this as any. But reading your work so far has helped my to clarify some of my murky misgivings about the way my work experience has gone.
I think that allowing the dev team to work completely uncoupled from the database has certain unintended consequences. Namely, that the developer is not required to understand the data conceptually. Sure you might (or might not!) understand the types involved, but understanding the meaning behind the pieces of data you are working with isn't required in the way it is if you are working closely with the database.
So on one level, at least, I think that it's very difficult to really understand the business logic you are supposed to be implementing as a developer if you do not have a clear understanding of what the data really represents. In allowing a lot of separation between the developer and the database, you are allegedly freeing the developer up from those worries so that he or she has more time to work on the application layer and it's business logic. But in doing so, it seems that you make the developer unqualified to actually write the app logic. Or at least, you don't force the dev to get qualified.
I don't know, those are just my thoughts are probably fairly biased because of my DBA background. But in my experience, I spend a lot more time feeling lost or at least unanchored and doing some guessing about things as a developer when I'm not working with the database than I do when I am. I'm still pretty green as a developer, so I'm sure that's some of it. Maybe other devs are just smarter than me. But it's a feeling I can't shake: I need to know what's going on in the database in order to do a good job of writing the app.
I'm not sure I understand you correctly. But you seem to imply that I make a case that you, the developer, are only allowed to work in the 'UI-technology du-jour' outside the database. Depending on the context and what you mean by 'developer', that is actually true. Let me try to elaborate/explain.
One of the central viewpoints in the Helsinki Declaration are the code-layers as described here:
"That's why I repeat here, that in order for the Helsinki approach to succeed, you'll require: 1) Educated database designers, ... 2) Experienced plsql developers, ..."
The developer resources described above are responsible for implementing the data-logic and business-logic of the application. Now *if* these developers are versatile in that they also master the UI-technology du-jour that is being used then, by all means, they are also responsible for implementing the UI-logic. And so you the (UI-)developer 'understand the data conceptually' and 'understand the business logic' built on top of the tables, since you actually all do that.
However I rarely see these capabilities combined in a developer. Most developers nowadays are masters in some technology outside the database. This technology is used to develop the UI-layer and, by the way, this technology also has the possibility to build BL- and DL- code. So what do these developers do? They have the hammer..., so we end up with a non-Helsinki compliant architecture.
In this case I advocate, for Helsinki to succeed, to bring database experts on-board. And put them in the drivers' seat. This ofcourse demotes the role of the (UI-)developers tremendously: they are now only responsible for UI-code and interfacing with the database using the pre-build/designed-by-contract database API's delivered by the database experts. Mind you the database experts are now end-responsible for the whole application, in that they will need to understand what UI needs to be built, and how. For only then can they develop the right database API's.
Needless to say that a critical successfactor in this scenario is that they all work as a team with a common goal of delivering a database application that works.
I'm sorry, I think I was unclear. I wasn't trying to rephrase anything you said. I was (perhaps unfortunately) trying to add to what you were saying with my own experience. I'm half DBA and half OO framework du jour developer.
I don't get a huge amount of choice about what I use at work.
Perhaps I'm versatile. It's possible. I am at different times assigned to different tasks. Sometimes I'm DBA. Sometimes I'm OO business logic guy. Sometimes I'm UI. It depends on who needs what and when and how fast.
My comment above really reflects my thoughts about my own work and the fact that I don't think I do good work when I'm forced to be separated from the database. My only point was that I've seen this from a number of different sides. Out of all the sides I've seen, I like your ideas the best. So thanks.
Your book arrived this evening, and I'm looking forward to digging in. I think I'm going to get a lot out of it.
We are ERPTREE Leading oracle fusion HCM Online Training institute. We are providing online training services since 1999. still we are adding more oracle related courses as the technology changes. 2000+ online courses are available. we all ways achieve our goal in satisfying students in result we have global recognition to our site. we have best faculty for all of our online courses.
Hi there, I just wanted to say thank you for this series. I'm a developer who started years ago as a DBA, and I've long had this thought that keeping "business logic" out of the DB was a bit of a crazy prejudice.
ReplyDeleteI've very much enjoyed finding out that there's someone else who has given a lot of thought to designing things a more sane way. This has been a great read, so has the trigger blog. A copy of your book will arrive at my house tomorrow, and I'm very much looking forward to reading it over the Christmas and New Year's holidays.
I hope you find time to finish this series at some point.
Thank you,
-andrew
I guess this is as good a place to say this as any. But reading your work so far has helped my to clarify some of my murky misgivings about the way my work experience has gone.
ReplyDeleteI think that allowing the dev team to work completely uncoupled from the database has certain unintended consequences. Namely, that the developer is not required to understand the data conceptually. Sure you might (or might not!) understand the types involved, but understanding the meaning behind the pieces of data you are working with isn't required in the way it is if you are working closely with the database.
So on one level, at least, I think that it's very difficult to really understand the business logic you are supposed to be implementing as a developer if you do not have a clear understanding of what the data really represents. In allowing a lot of separation between the developer and the database, you are allegedly freeing the developer up from those worries so that he or she has more time to work on the application layer and it's business logic. But in doing so, it seems that you make the developer unqualified to actually write the app logic. Or at least, you don't force the dev to get qualified.
I don't know, those are just my thoughts are probably fairly biased because of my DBA background. But in my experience, I spend a lot more time feeling lost or at least unanchored and doing some guessing about things as a developer when I'm not working with the database than I do when I am. I'm still pretty green as a developer, so I'm sure that's some of it. Maybe other devs are just smarter than me. But it's a feeling I can't shake: I need to know what's going on in the database in order to do a good job of writing the app.
-andrew (again)
Andrew,
ReplyDeleteI'm not sure I understand you correctly. But you seem to imply that I make a case that you, the developer, are only allowed to work in the 'UI-technology du-jour' outside the database. Depending on the context and what you mean by 'developer', that is actually true. Let me try to elaborate/explain.
One of the central viewpoints in the Helsinki Declaration are the code-layers as described here:
http://thehelsinkideclaration.blogspot.co.uk/2009/04/helsinki-code-layers-in-dbms.html
Quoting from that post:
"That's why I repeat here, that in order for the Helsinki approach to succeed, you'll require:
1) Educated database designers, ...
2) Experienced plsql developers, ..."
The developer resources described above are responsible for implementing the data-logic and business-logic of the application.
Now *if* these developers are versatile in that they also master the UI-technology du-jour that is being used then, by all means, they are also responsible for implementing the UI-logic. And so you the (UI-)developer 'understand the data conceptually' and 'understand the business logic' built on top of the tables, since you actually all do that.
However I rarely see these capabilities combined in a developer. Most developers nowadays are masters in some technology outside the database. This technology is used to develop the UI-layer and, by the way, this technology also has the possibility to build BL- and DL- code. So what do these developers do? They have the hammer..., so we end up with a non-Helsinki compliant architecture.
In this case I advocate, for Helsinki to succeed, to bring database experts on-board. And put them in the drivers' seat. This ofcourse demotes the role of the (UI-)developers tremendously: they are now only responsible for UI-code and interfacing with the database using the pre-build/designed-by-contract database API's delivered by the database experts. Mind you the database experts are now end-responsible for the whole application, in that they will need to understand what UI needs to be built, and how. For only then can they develop the right database API's.
Needless to say that a critical successfactor in this scenario is that they all work as a team with a common goal of delivering a database application that works.
Toon
I'm sorry, I think I was unclear. I wasn't trying to rephrase anything you said. I was (perhaps unfortunately) trying to add to what you were saying with my own experience. I'm half DBA and half OO framework du jour developer.
ReplyDeleteI don't get a huge amount of choice about what I use at work.
Perhaps I'm versatile. It's possible. I am at different times assigned to different tasks. Sometimes I'm DBA. Sometimes I'm OO business logic guy. Sometimes I'm UI. It depends on who needs what and when and how fast.
My comment above really reflects my thoughts about my own work and the fact that I don't think I do good work when I'm forced to be separated from the database. My only point was that I've seen this from a number of different sides. Out of all the sides I've seen, I like your ideas the best. So thanks.
Your book arrived this evening, and I'm looking forward to digging in. I think I'm going to get a lot out of it.
-andrew
We are ERPTREE Leading oracle fusion HCM Online Training institute. We are providing online training services since 1999. still we are adding more oracle related courses as the technology changes. 2000+ online courses are available. we all ways achieve our goal in satisfying students in result we have global recognition to our site. we have best faculty for all of our online courses.
ReplyDeleteOracle fusion HCM Online Training