Why do most people say that data services and the database are the most important parts of a system?

Question

Why do most people say that data services and the database are the most important parts of a system?

From what I have seen, it is the front end development: GUI, WEBUI, XAML that is the most important. Certainly more important than the middle and database tiers.

I don't think it is a big deal to build an application's database. After all, the data schema comes from the business analysis and there is very little "creative" work on the part of the database developer. The same is true for the business logic side (middle tier). In addition, J2EE and the .NET enterprise framework both help to make the business logic simple to develop.

So, what is the database developer doing that is so important? Why do we even need a standalone database developer? Why do most companies still pay a higher salary to middle/backend developers instead of front-end developers?

I believe that developers building the UI (in Java or C#) should have database knowledge. This would let them build the entire application. In my view, it is impossible to let a not-database knowledge person develop the application anyway.

Please let me know what I am missing here.

Thanks a lot.

Answer 1

I believe the front end side: GUI, WEBUI, XAML is more important than middle tier and database tier.

That's kinda like saying the color of a car is more important than the engine and the tires.

It's probably not a big deal to build a database. It is, however, a big deal to build one correctly, optimize an existing one, and maintain a well-designed data store. IMO, that is why database/datastore guys get the big bucks.

Answer 2

Among many other reasons: With a solid middle tier, you can switch from one GUI to another based on requirements.(say from pre web2.0 to web2.0 design) So A lot more planning is needed for middle and backend tiers compared to a possibly exchangeable frontend.

Answer 3

It's all important.

Answer 4

it's impossible to let a not database knowledge person to develop any application.

Not if you hide the database tables with stored procedures wrapped in web services.

The front end is merely a skin over the real application.

The middle business tier is the most difficult to program IMHO as the business people rarely know what their requirements are, despite thinking they do. They change their minds regularly. Edge cases wreck a nice design and can be very difficult to implement.

It doesn't matter how good your GUI developer is if he's writing a front end on a poorly written business tier. And you can't write a good business tier on a poorly designed database.

In the end, it's much simpler to rewrite a GUI than it is to change the database layer or middle tier, as a change in either of those affects all the subsequent levels of the program.

Answer 5

The front end is usually much easier to change while the backend needs a more through requirements and design phases. If there's a change to the backend, then the front-end will most likely need to change, so change requests dealing with the backend services (db, etc.) will often result in lots of changes through the middle and front ends. A change in the front end usually doesn't affect the backend.

The DBA issue really depends on the size of your project. If you're talking about projects with a few simple tables and a few thousand records, then you're probably right. A real DBA would probably consider that beneath his/her worth to work on that project anyway. A real DBA is more like a systems administrator that specializes in DBMS optimizations. Nearly any programmer can build tables, relationships, views, stored procs, etc. And especially with easy to use ORMs, a lot of the stuff that DBAs used to do isn't really needed. However, a DBA is crucial when working on large projects and large database systems for DBMS optimizations, system configuration, failover configuration, etc.

Your original question doesn't talk about the project scope and I think that's where you're confused or don't see the importance of a real DBA (not to be confused with someone that knows a bit of SQL or does data entry and call themselves a DBA).

Answer 6

For a small app that you throw together the database doesn't seem that important, but let that app grow and evolve over time and you rapidly run into pitfalls due to poor design.

The database layer and middle-tier are the keys to the longevity and maintainability of your app.

Answer 7

Logic of business always be simple with J2EE or DotNET enterprise framework help.

Sure, coding the business logic tends to be straightforward...if you don't have to worry about exceptions, error handling, actually getting the right requirements from the business, etc. Add in the ability (needed now more than ever) for a single application to support multiple front-ends (web, desktop, mobile), and all of the sudden that "simple" business logic become a critical point.

Answer 8

Some of the most challenging work I've done as a programmer is dealing with user interfaces (xhtml, xaml, servlets, mvc, asp.net etc). That being said, I think you're running into two different issues. On the database side, as Mathew said, a true DBA is going to be able optimize a large (millions of records) database in ways a regular developer will not know how. On the middle tier, I think the reason the UI is often so complex is because often the developer doesn't really build a true middle/business logic tier. So they end up putting all the logic in the application in the user interface, which is wrong. Finding good developers who know how to build a solid, object-oriented business layer who know domain driven design and OO design patterns is RARE. Build a bunch of classes with just getters/setters that match your database objects is NOT object oriented design. Hence they are worth more.

Other than that, I agree that still, UI work is very challenging programming and should be considered more important than it currently is.

Answer 9

It is impossible to answer your non-question.

It is based on a premise that everyone thinks the database is the most important thing in all systems - which is false, obviously - not only do all people not think that, many systems do not use databases and many experienced people will agree that the most important parts of different systems vary from system to system.

In fact, by the definition of a system, every part has to be important! It's possible that some subsystems can be more expensive than others, some more fault-tolerant that others, some replaceable in a modular fashion and others not, but all are PART of a SYSTEM, and thus ARE important. The idea that one is more important is hard to quantify. It's conceivable that some parts are optional (like "unfunctional" decoration), and thus might not be considered part of the system. However, in the larger view of the system, users participate and their efficient and joyful interaction with the system is vital to ensuring its success.

To use an analogy already posted here, the paint on a car might not be as important as the engine, but would someone sell an unpainted car? - not likely (unless that was the definition of the product - like unfinished furniture).

In the same way that an engine is more expensive than a paint job, I would expect we pay people more to design engines than to select colors of paint.

There's a spectrum of specialties and complexities in all systems.

Answer 10

It doesnt mean everybody can code well in VC++, even though they have a knowledge in c++.

In current technical world, every developer got basic knowledge about most of the latest technologies. It doesnt mean they are ready to design a system with all the technologies.

Its all comes with experience and your specialization. Remember they paid well for doing DBA, not doing UI design.

It doesnt mean UI developers cannot design a DB. You can also become a good DB designer, if you have enough experience with design a database.

Cheers

Ramesh Vel