Design: Central or Divide & Conquer?

[Kevin Sprinkel]

We estimate construction projects at various stages of
architectural design, and are in the process of developing
a database application that manages various administrative
functions--billing, performance history, scheduling, etc.

We estimators have developed several smaller apps to
assist in the takeoff and pricing process, and have others
planned, which would need information from the central DB--
client name, date, phone numbers, etc.

We would appreciate input from experienced DB designers as
to whether we should create a separate "Mini-Apps" DB,
linking in tables from the central DB as required, or just
keep everything together in one .mdb file. E.G., since we
will routinely interact with the central DB and then wish
to launch a mini-app, is it possible to put such a menu
choice button on the central DB switchboard form that
would close the DB, open the mini-app DB, and choose the
app that was selected from the original switchboard?

Thank you for any guidance you can provide.

Best regards.
Kevin Sprinkel
Becker & Frondorf

 

[John Nurick]

Hi Kevin,

Other things being equal I'd probably use one back end to contain all
the data. For the front end(s), I feel it depends largely on user needs
and perceptions (or what you want them to perceive).

For instance, if the estimators don't need most of the standard
functionality of the admin database and you want them to feel they have
their own app, build what they need into a separate front end.

OTOH if there's a lot of overlap between what the various groups of
users need (or you want people to feel there's one key company-wide
application) build the extra functionality into the admin front end (and
if necessary hide it from users who shouldn't have it).

I'm working towards three front ends for a company DB at present: one
"main" (find information about jobs, contacts, contact lists, sales,
documents, tasks, and lots more) which almost everyone uses many times a
day; one that gives access to market data (which most people will never
use); and one, very skimpy, where the user can write SQL queries to
construct custom contact lists (which about two people will use about
once a month). Some functionality in the "main" front end is only
exposed to certain users.

 

[Guest]

Thanks for the input, John, it helped clarify my thinking.

 

[John]

Hi Kevin,

If you would consider upgrading to SQL Server

I have written an application generator that allows developers to
build business applications for MS SQL Server in just a fraction of
the time it used to take. All you need to do is create the tables and
answer a few yes or no questions about each table. The generator does
the rest.

In order to demonstrate the my generator to developers, I am issuing a
promotion:

The Promotion will cost you nothing. All you have to do is send me the
TSQL scripts necessary to create your tables and to define the indexes
and foreign key relationships or I can create them for you. My
generator will do the job, and I will deliver the finished and fully
functional UI.exe along with a finished and fully functional SQL
Server back end which contains a robust security system and a
comprehensive data dictionary, completely free of charge.

The benefits of this system are as follows:
1. The system generates true Client Server and Multi Tier
applications.
2. There is Zero Coding for common functionality such as;
Adds, Updates, and Deletes,
Creating application wide unique Ids for each record,
Maintaining an Audit trail for each table,
Posting to the general ledger,
Rolling down changes to dependent tables,
Cascading deletes,
Transactions and rollbacks,
Calling validation and business rule stored procedures,
Calling post processing stored procedures,
Importing and revalidating data,
Security,
Spell checking, language translation and more.
3. There is zero work of any kind for generation of data entry
screens and their lookups.
4. The back end is completely independent from the front end. You can
hit the database with any application or user interface and still be
sure that you have complete security and valid data.
5. Easy navigation through out the application. The generated user
interface is a familiar modern metaphor with a navigation tree on top
or at the side and data entry screens at the bottom. Also, the
generated user interface remembers customizations to each data entry
screen. This allows you to make sweeping changes to the interface, and
regenerate all data entry screens, without loosing your
customizations.
6. Consistent look and feel via OOP Inheritance and code generators.
7. Major changes in look and functionality are made in one place
only, and ripple down to all affected parts of the system without
programmer intervention. Again, this was accomplished with OOP
inheritance and also with code generators.
8. Users to have the ability to create queries and reports on the
fly. And the ability to save and reload those queries and reports in
many formats including Excel and HTML.
9. Users to have complete flexibility in customizing the look and
feel of the system. The extent to which each user can customize the
interface must be seen to be believed. This high level of
customizability creates a high degree of user acceptance.
10. Logical use of hot keys and local popup menus allow for easy mouse
free operation, permitting the user to keep his or her hands on the
keyboard, if the user so desires.
11. All custom code added to generated data entry screens and
generated backend code persists after regeneration.
12. Comes with a business rule generator
13. Comes with a data import utility
14. Comes with a data revalidation utility to use when you change your
business rules.
Get all this without programming.
If you need to quickly build feature rich, bug free business
applications for MS SQL Server, then please call (201 665 8906) or
write to (e-mail address removed)