Re: Data-aware GUI controls

From: Patrick May (pjm_at_spe.com)
Date: 08/22/04 

Date: 22 Aug 2004 21:45:16 +0100

fredrik_bertilsson@passagen.se (Fredrik Bertilsson) writes:
> > Throughout each application's lifetime, the schema is likely to
> > change for reasons unrelated to the application.
>
> I would say the opposite, throughout the lifetime of the database
> schema the application is most likely to change.

     I was under the impression that we were discussing enterprise
systems. These types of applications access multiple, shared
databases that are not owned by the application. Applications
certainly change, but so do schemas and the lifecycles of the two
should not be coupled.

> There are many examples of enterprise applications written orginally
> in Cobol and later rewritten in modern languages, but the most of
> database schema is the same.

     "Most" is a very key word here. Schemas do change and change for
reasons related to only one of the many applications that use them.
Failing to insulate applications from these changes leads to brittle
systems that can't be changed because of the ripple effect on other
unrelated components.

> > > A good software design always starts with a careful database
> > > design.
> >
> > False. A good software design starts with an understanding
> > of the business functionality and behaviors required to provide
> > value to the customer.
>
> I think that many developers will disagree with you.

     They'd be wrong, then. There's an old saying that no one wants a
drill, but people occasionally need holes. The data, DBMS, and
software in general are of no interest to the vast majority of
businesses, but support for business functionality is essential. That
functionality is why customers pay for systems to be built.

> For example, ask someone doing data warehousing. The business data
> is not only accessed through enterprise applications. Reports and
> queries are also done with standard report and DW tools. It's
> extremly important that the data is carefully designed from the very
> beginning.

     I have not suggested otherwise. It is very important to use best
practices in designing database schemas. It is very important to use
best practices when designing business logic and functionality. It is
very important to decouple the two.

> > > Redesign of the database will almost always lead to a change in
> > > the application code, whatever arcitecture is used.
> >
> > False. Changes to the schema that are not related directly
> > to application functionality need not, and should not, affect the
> > application. As an example, denormalization for performance
> > should not impact the user interface.
>
> Yes, the only database changes you can do without changing the
> application is performance optimization. But (all other) changes
> caused by feature requests will of course always affect the
> application too.

     Absolutely false. Changes that support new applications or
modifications to other applications (we're discussing enterprise
systems here, remember) can also be made without impact to a given
application. More drastic changes to the entities and relationships
that still support the abstractions required by the application can
also be made.

> > > If you have a "Customer" table, you will most likely have a
> > > spreadsheet in your client which will show "Customer" records.
> >
> > This may be the case in a simple CRUD application, but is
> > increasingly unlikely in large distributed systems.
>
> You think it is unlikely to have a spreadsheet showing customers in
> a large distributed system? I can tell you that every major ERP
> system has.

     Not every component or application that uses customer information
in the system will have a GUI of any kind, let alone one with a
customer "spreadsheet". The majority of components will have
different views of what exactly is meant by "Customer" and in many
cases that view will change based on the internal workflow. Coupling
every component of a distributed system to the specifics of a database
schema is a recipe for an inflexible failure.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)

Relevant Pages

  • Re: Database abstraction layers (summary)
    ... RAD applications in MS-Access. ... the main reasons I began developing in PHP is that it is a total PITA ... Now I'm trying to do the same with the database. ... Metabase can take database schema definitions in a RDBMS independent XML ...
    (comp.lang.php)
  • Re: Java is becoming the new Cobol
    ... In the Unisys 2200 environment using their Network Database Server, you get a schema work area depending on how you invoke the schema. ... However, it not only copies the schema area into the program, but the "DMCA" (Database Management Communication Area - basically, the block of information that holds your connection state) is copied in too. ... So, you're left with working-storage, which makes it visible to your program only, or common-storage, which makes it visible to programs linked in. ...
    (comp.lang.cobol)
  • Re: Renaming databse objects
    ... we may need to change the database name and in some cases want to rename ... existing database objects. ... Just in case this database object renaming project is in response to ... Create a new schema, ...
    (microsoft.public.sqlserver.programming)
  • Split messages
    ... This is based off the northwind database. ... Create document schema: ... Select the SQL entry, make sure that we are pointing to the SQL ... For the item select a receive pipeline and name it EmpSplitPipe.btp. ...
    (microsoft.public.biztalk.general)
  • Renaming databse objects
    ... While working on an existing database, we may need to change the database name and in some cases want to rename existing database objects. ... Just in case this database object renaming project is in response to ... Create a new schema, ... The schema with the original column names is still there, ...
    (microsoft.public.sqlserver.programming)