March 7, 2009 at 11:02 am
Comments posted to this topic are about the item What comes first, the application or the database?
March 7, 2009 at 3:04 pm
I do not get the problem of coding from the ground up. I have been doing it that way for over a decade - see no problem with coding SQL DDL and DML and doing it by hand, wiring the database architecture into business objects and creating a UI. I have also witnessed what happens when there is a disconnect between the data architecture and business and UI architecture - you end up with a overly complicated system that is, for all intents and purposes, unmaintainable and unintelligible. There is no reason to thumb your nose at SQL - its a language just like C# or VB or Java. You are better off knowing your way around it than ignoring it.
March 7, 2009 at 6:30 pm
1. Heavily normalised data structure.
2. Stored procedures implement the select, insert, update, delete statements on the database side and the ensilo'ed (!) business logic on the application side. Heresy, business logic on the database server, not the application server.
3. Application implements the translation between the UI on the user side and business logic on the database side.
Adavantages.
DBA doesn't have to compromise the data structure for the analysts and programmers.
Multiple silos sharing common aspects can have genuinely common data.
Programmer doesn't have to compromise the business logic behind the UI for the DBA or the UI in front of the business logic for the analyst.
Someone has to write seriously cool SP's.
Disadvantages.
Analyst has to appreciate the heretical concept of separating UI from business logic from data storage model.
Bigger database servers, smaller application servers.
Someone has to write seriously cool SP's.
-----
If you didn't see it here first, you're a dinosaur.
:Whistling:
Peter Edmunds ex-Geek
March 7, 2009 at 6:36 pm
Very true. I believe developers who build enterprise systems need to understand the architectural overview of where their system fits into the bigger picture, and the value of an optimized data model that can meet downstream needs as well (even if they can't build it). I definitely understand the "impedence mismatch" of hooking into, say, a complex CRM schema and then wrapping business rules around it while trying to present unified entity views in the application. The article sounds like DDD takes a customer object, serializes it and dumps it into Customers.xml or an XML field. I can see how this would speed your development time...
Does DDD just dump Entities into a Repository from the business tier in their current state? Or can it coexist with a normalized, storage/retrieval optimized data model?
March 7, 2009 at 9:49 pm
I have been on both sides of the coin (i.e. DBA & Developer) and currently do a bit of both in my existing role. I have found that both approaches have merit but this whole discussion is becoming more and more redundant due to the emerging of better ORM (Object relational mapping) systems. You can take a DDD approach as a developer and still interoperate reasonable seamlessly with a relational database with neither parties having to compromise particularly (especially if abstraction is done through stored procedures or the like).
Its worth the time and investment to look into a good ORM (maybe coupled with some form of code templating) for most sized projects bigger than the most basic.
Just my two cents worth
March 8, 2009 at 4:06 pm
So what is the answer? Design the DB or Design the application?
I would think it could go either way.
Define your classes and then the database could be designed OR you could design your RDMS and build your classes as the database defines.
I think it varies depending on the solution you are trying to provide.
Thoughts?
March 8, 2009 at 5:16 pm
Hey there moojjoo.
I've no intention of starting a flame war here, just maybe another 20 years in the industry could help answer the question.
In lieu of that however...
A UI has a set of design principles, people think in a relatively limited way, on average, about the task in hand, so there should be no extraneous data or tasks presented by the UI. I'm inclined to say that this is slightly more of an art form than a science.
The business logic has any number of sets of design principles from which to choose, but this is where the real engineering comes into play, ensuring that the minimal set of data on the UI is able to be translated to and from the entire dataset, via a set of proveable rules, with which the application is dealing.
Then the real art form comes in to play, and I'm talking about the data architecture here, not the ramifications of the architecture on the disk RW issues. That may well annoy a few DBA's reading this, but after being involved in the industry from back into the history of IMS/DB and with RDBMS's since DB2 1.2, I've developed the occasional opinion along the way.
I've very strong opinions in favour of 5-normal in a commercial environment. Oh dear, heresy again. That's at the table level, don't care what you do at the application side of an SP, just DO NOT let the the analysts and programmers on to the DBMS side of the SP unless they are able to talk cogently, at length, on the fly about 6-normal and it's applicability in class persistance.
Peter Edmunds ex-Geek
March 8, 2009 at 5:34 pm
In case the previous post wasn't entirely clear there are three major, probably seriously conflicting, sets of of designs that need to be accounted for in any application. As succinctly as possible:
UI rules
Business rules
Data rules
The scale of the app will determine the initial weighting given to the predominant player, the available budget will determine the final predominant player and which other two players will be compromised.
-----
If you didn't see it here first, you're a dinosaur.
:Whistling:
Peter Edmunds ex-Geek
March 9, 2009 at 2:13 am
The only problem is (still) the ego of the developer...
If one would take the time to really investigate the scale of the business process at the end-user level and combine this with the information need of the management the result is a proper normalized database and a proper workflow. If a proper finite state machine methodology is chosen and a proper set of GUI templates is defined, all that is needed is a team of developers that are willing to co-operate and see the new system as a joint effort. This opposed to the "look how clever i am because i will decide what you need" approach resulting in the dreaded "information islands".
In my opinion the data <> application is rediculous: any application without data is useless unless you like to type "Hello world!" all day. A database can always be queried, delivering a set of information (if queried correctly) that is comprehensive and can be used by any application.
Therefore, developers that start building applications without a proper data model have no place in a professional environment.
March 9, 2009 at 5:02 am
Tony, great thought provoking article (as we have already seen)
What we really need to define is "traditionalist". A "traditionalist" developer (read mainframer) built everything from a silo perspective. Address the business need and the business need only. "Oh, you want one app to talk to another? Sure, we can develop a translation piece for that". I feel mainframers were bound by the culture they lived/were raised in. A "traditionalist" DBA built everything to be shared. In their "upbringing" there was a great cry for inter-operability. In the spirit of total exposure I am a developer/DBA of the latter tradition. Now we have push back that the silo approach is best.
The problem has always been that neither approach makes everybody happy. The "best" approach has always depended on which side of the road you are looking from.
Second bit (no pun intended):
I don't think a "data bases" that is a "better ORM (Object relational mapping) systems" is saying much. We never have wholesale shifts in paradigm just because marketing says so. Oracle has been saying for many years that their DB is an ORM system. The truth is it can hold objects, not that it relates them. You want the best performance stick to the data base strength, relational not object. No offense intended, but Oracle might just be getting good at it, but they are not great and Oracle is ahead of SQL Server on this front.
Third bit:
Peter, another twenty years in the industry and we will be having this same conversation again, just on a different topic. Not that I have been around for 20 years of industry.
<><
Livin' down on the cube farm. Left, left, then a right.
March 9, 2009 at 6:20 am
" Developers, of course, hate being forced to work "from the database up". "
Do we? I've developed for many companies and common practice had been that us developers develop the database and then write the application with a bit of sense checking by a DBA inbetween or work with a given database. I don't see how you could easily create a decent application by reversing the process.
March 9, 2009 at 7:22 am
Interesting article... my company has created a niche in campaign management software by creating an "open-architecture" product. If the underlying tables in the database change, the product reflects the change. This does, however, require much more intelligent users.
I, for one, am entirely in favor of building the database first. Maybe I'm missing something, but why does the article assume that the database will only be used by one tool? We recently built a database for a client who is using three separate tools (by three different companies), but since each tool communicates directly with the database they can operate independently in unison with each other. This would not have been possible if we had built the database with one specific tool in mind. I think we are moving past the days of forcing the database into a specific format for a tool to work.
March 9, 2009 at 8:32 am
Tony, Great topic and your writing is superb!
Everyone's responses are good too! Everyone seems to have a good point to add to the discussion.
I believe that every company does their development slightly differently from each other. I don't believe that there is any one right or wrong way of doing things. I do believe that both programmers and DBAs should develop in parallel. The requirements of the project should be presented to both programmers and DBA at the same time and both parties should meet at least weekly to prioritize, design and test in conjunction with each other.
Stored procedures (complied) are certainly the best way to transmit data to and from the database and application. However, let’s not forget how VIEWs can be used to help make life easier for developers and DBAs who write the stored procedures.
Like all other human relationships, there’s both a give and take balance that needs to be maintained. The more DBA’s give to Developers, the more Developers are willing to adhere to standards. Communication is always a key factor. Constant communications and with developers and management go a long way toward success.
May everyone have success in their development and developer relationships.
March 9, 2009 at 9:27 am
I think there should be a voting poll performed, but if that was built do you build a one off application or do you build a database to extend the poll application to perform many polls. HA HA HA. And th discssion goes on.
Any way the question still remains - database first or application.
In my career I have always worked backwards from the design phase of a project. What does the client want out of the applicaiton because in the end who are you trying to please. In the big fortune 500's? ummm... Senior Management and Executives. And what do executives need to see? REPORTS.
So you better have the data in those RDBMS to provide reports to those executives.
What does everybody else think?
March 9, 2009 at 4:27 pm
I'm mostly in line with moojjoo. I can't imagine even starting on designing a database without having a clear idea of what the user wants. Sure, figuring out user's needs starts with interviewing them, but the next step in designing an application is to show the users a prototype, not design a database. A prototype provides the users with enough information that they can buy-off on the project. The users can NOT buy off on a database design or a simple printed list of requirements. The beauty is that once you have a prototype, knowing the correct database to build should be a snap.
However, I also can't imagine being able to create a decent prototype without thoroughly understanding relational databases and seeing in your mind what the tables and databases would look like to support the screens included in the prototype. I often discard several prototype designs because I know they will not work well with relational tables.
In other words: I don't see application design as a complete either-or process. The person designing the application needs to understand both the business needs and good database design practices in order to come up with a good final product. They are intertwined, so why would you develop one completely independently of the other? That would be a mistake.
Then again, I do both functions. It's not a me-them situation at my agency. Maybe it is easier for me.
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply