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 Monday, March 9, 2009 6:20 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, August 28, 2013 6:59 AM
Points: 149, Visits: 51
" 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.
Post #671390
Posted Monday, March 9, 2009 7:22 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, June 19, 2014 2:01 PM
Points: 54, Visits: 35
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.
Post #671452
Posted Monday, March 9, 2009 8:32 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, June 5, 2014 6:50 AM
Points: 13, Visits: 134
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.

Post #671558
Posted Monday, March 9, 2009 9:27 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, May 7, 2014 8:26 AM
Points: 19, Visits: 79
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?
Post #671634
Posted Monday, March 9, 2009 4:27 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 1:15 PM
Points: 266, Visits: 2,568
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.
Post #672037
Posted Monday, March 9, 2009 8:18 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
Ok, I am quite prepared to start a flame war over this silliness.

"knowing the correct database to build should be a snap"

Go back to school JJ B, then get a job and do some "real" work for a few years before starting into the group of -hugely- experienced people who this forum represents. Or for that matter, before starting into the uneducated neophytes of the DP, IT, IM, ITC... industry of whom I'm a representative.

There are a number of threads on this site related to idiocy, perhaps the moderator could move this thread there, then if s/he wishes, ban me for my deliberately inflammatory statements.

If I'm still live here after this post, then, JJ B, try building a group of tables that store international physical and postal addresses, with a perorg relationship (where the person and organisation are included), and each person can be represented in multiple organisations, with temporal integrity, and each organisation has multiple international postal or physical addresses, with temporal integrity, and each person has multiple international postal or physical addresses, with temporal integrity, in 5-normal then come back to this forum and demonstrate that "the correct database to build should be a snap".

Else, oh I don't know, go and drink a quart of bourbon and hope the problems go away.

But please please please, DO NOT implement "the correct database" for any commercial organisation, regardless of how much they want to pay you, on the the basis of the erroneous "knowledge" that you present here.







Peter Edmunds ex-Geek
Post #672100
Posted Monday, March 9, 2009 8:41 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
As for "buy off", go back up a few entries in this this thread, generally the UI is what is in the forefront of the the person signing off the development expenditure, not the normalisation of the data, nor the impact on the database or application servers, unless an over budget upgrade is required, nor the impact on other silo's data, nor the impact on the technical team.

No ifs, no buts, no maybes, someone who is sufficiently into the marketing view that they have got to the point where they are signing off the expenses of major corporate development is not going to care what any techie says about long term, cross application data viability. Their job, probably 99% of the time, just will not sustain it, so it's up to the grunts to carry on and do the job correctly and hope that the UI is not so far from the currently available technology that a few months of unpaid overtime won't be able to fix the issues.

Otherwise the marketers are going to be looking for roast geek at the next corporate didntwedogreat fest and the geeks will have to wait a little longer before inheriting the Earth.


Peter Edmunds ex-Geek
Post #672112
Posted Tuesday, March 10, 2009 7:37 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
Wow, Peter, I don't think JJ B deserved the intensity, you do make some valid points however.

JJ B, It is possible for a data base to fall out of a prototype, but that has not been my experience.

I think this discussion started with the premise that "we have the requirements, should we develop the app or the data base first", at least that is the way interpretted it. I do not think many successful company's develop apps or data bases and then say "hey!, let us go see who wants/needs/can use this".


<><
Livin' down on the cube farm. Left, left, then a right.
Post #672423
Posted Tuesday, March 10, 2009 9:14 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, February 18, 2014 7:14 AM
Points: 1,344, Visits: 1,983
I think JJ B is over-sipmplifying a bit, but I think what he's getting at is similar to my experience.

First you get the request, from which report layouts and display mock-ups get build (non- or semi- functional prototypes). From this the full requirements for data gets constructed, after which the database isn't quite "a snap", but is a fairly logical operation. Finally, or more often in parallel with the database build, the final application actually gets written.

So, in a way, neither the application nor the database come first. The application starts first, but the database finishes first!


Derek
Post #672533
Posted Tuesday, March 10, 2009 6:56 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, May 7, 2014 8:26 AM
Points: 19, Visits: 79
Ok, this disscussion has been great.

Let's remember - Database or Application first; That is the question?

I wish the business would know that question before trying to build solutions out of tools such as Microsoft SharePoint flat tables with zero relationships, but one big huge 100 + columned table, then ask the technical team to build reports from it. Fun fun fun...

So then I ask the question, how do you tell the business that they should not be trying to build solutions without an custom application or database.

:) CHEERS....

By the way, I truley believe in having a project kick off once a Charter and Business Requirements Document is produced and that kick off includes

Enterprise Architect
DBA LEAD
Application Developer Lead
Tester LEAD

I believe it is esitial to have those folks in from the get go.

That way you have everyone working together.
Post #672917
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse