SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Tony Davis / What comes first, the application or the database? / Latest Posts

RE: What comes first, the application or the database?

JJ B — Wed, 11 Mar 2009 09:30:44 GMT

Let's not get side-tracked. My main point is that it isn't a one-sided process, but an intertwined process. I didn't mean to hurt anyones feelings/ego. If building databases has been a very hard process for you, I'm sure you get the job done. No one is insulting your no-doubt expert hard work. I hope you get all the validation you need. Peace bro. Life is short.

RE: What comes first, the application or the database?

Tobar — Wed, 11 Mar 2009 06:12:23 GMT

I'm a lover, not a fighter. :-) Well, not really, but since Jacko is on the come back trail (ack, ack, thppbt) the phrase came to mind.

RE: What comes first, the application or the database?

wldhrs — Tue, 10 Mar 2009 21:40:13 GMT

Tobar, I didn't get the title of Mr Diplomacy from several of New Zealand's larger coporates by being subtle. :)moojjoo, y'all jus redeemed yourself with the comment about sHAREPOINT (doesn't deserve a leading cap and has an overinflated opinion of its place in the market).All that's needed now is to overlay the sharepoint experience on to general application development and you'll find a representative of just about every evil that has inflicted development of moderately kosher systems since Windows itself (in spite of everything people may say to the contrary, I still think is does deserve a leading cap) introduced class concepts without rigorous polymorphic inheritance.C'mon, somebody bite.

RE: What comes first, the application or the database?

Tobar — Tue, 10 Mar 2009 19:17:08 GMT

just because people are all in the same room and nodding their heads nicely doesn't mean they are working together. :-)

RE: What comes first, the application or the database?

moojjoo — Tue, 10 Mar 2009 18:56:17 GMT

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 includesEnterprise ArchitectDBA LEADApplication Developer LeadTester LEADI believe it is esitial to have those folks in from the get go.That way you have everyone working together.

RE: What comes first, the application or the database?

Derek Dongray — Tue, 10 Mar 2009 09:14:18 GMT

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!

RE: What comes first, the application or the database?

Tobar — Tue, 10 Mar 2009 07:37:00 GMT

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".

RE: What comes first, the application or the database?

wldhrs — Mon, 09 Mar 2009 20:41:56 GMT

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.

RE: What comes first, the application or the database?

wldhrs — Mon, 09 Mar 2009 20:18:10 GMT

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.

RE: What comes first, the application or the database?

JJ B — Mon, 09 Mar 2009 16:27:50 GMT

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.

RE: What comes first, the application or the database?

moojjoo — Mon, 09 Mar 2009 09:27:08 GMT

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? [b]REPORTS.[/b]So you better have the data in those RDBMS to provide reports to those executives.What does everybody else think?

RE: What comes first, the application or the database?

Hyperdata — Mon, 09 Mar 2009 08:32:28 GMT

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.

RE: What comes first, the application or the database?

afowler — Mon, 09 Mar 2009 07:22:34 GMT

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.

RE: What comes first, the application or the database?

john.sims — Mon, 09 Mar 2009 06:20:36 GMT

" 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.

RE: What comes first, the application or the database?

Tobar — Mon, 09 Mar 2009 05:02:51 GMT

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.

RE: What comes first, the application or the database?

rob.geubel — Mon, 09 Mar 2009 02:13:20 GMT

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.

RE: What comes first, the application or the database?

wldhrs — Sun, 08 Mar 2009 17:34:28 GMT

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 rulesBusiness rulesData rulesThe 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:

RE: What comes first, the application or the database?

wldhrs — Sun, 08 Mar 2009 17:16:45 GMT

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.

RE: What comes first, the application or the database?

moojjoo — Sun, 08 Mar 2009 16:06:20 GMT

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?

RE: What comes first, the application or the database?

luke-946766 — Sat, 07 Mar 2009 21:49:05 GMT

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

RE: What comes first, the application or the database?

Christopher D. Kissinger — Sat, 07 Mar 2009 18:36:23 GMT

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?

RE: What comes first, the application or the database?

wldhrs — Sat, 07 Mar 2009 18:30:39 GMT

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:

RE: What comes first, the application or the database?

andy-463940 — Sat, 07 Mar 2009 15:04:54 GMT

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.

What comes first, the application or the database?

Tony Davis — Sat, 07 Mar 2009 11:02:07 GMT

Comments posted to this topic are about the item [B]What comes first, the application or the database?[/B]