Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

What comes first, the application or the database? Expand / Collapse
Author
Message
Posted Saturday, March 7, 2009 11:02 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Today @ 8:38 AM
Points: 569, Visits: 1,010
Comments posted to this topic are about the item What comes first, the application or the database?
Post #670946
Posted Saturday, March 7, 2009 3:04 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 1, 2012 11:46 AM
Points: 4, Visits: 17
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.
Post #671004
Posted Saturday, March 7, 2009 6:30 PM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, December 15, 2010 6:35 PM
Points: 63, Visits: 193
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.





Peter Edmunds ex-Geek
Post #671036
Posted Saturday, March 7, 2009 6:36 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 6, 2014 9:25 AM
Points: 1, Visits: 82
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?
Post #671037
Posted Saturday, March 7, 2009 9:49 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 13, 2010 6:33 AM
Points: 1, Visits: 19
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
Post #671058
Posted Sunday, March 8, 2009 4:06 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, May 7, 2014 8:26 AM
Points: 19, Visits: 79
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?
Post #671179
Posted Sunday, March 8, 2009 5:16 PM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, December 15, 2010 6:35 PM
Points: 63, Visits: 193
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
Post #671190
Posted Sunday, March 8, 2009 5:34 PM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, December 15, 2010 6:35 PM
Points: 63, Visits: 193
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.



Peter Edmunds ex-Geek
Post #671194
Posted Monday, March 9, 2009 2:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 1, 2011 6:58 AM
Points: 3, Visits: 59
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.


Post #671288
Posted Monday, March 9, 2009 5:02 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
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.
Post #671349
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse