[AccessD] Should Business use Access?

A few years ago, when working on one government project, (it was Oracle), the number of tables was such, that the layout of the schema covered two walls in my office. I honestly have no idea how many tables and queries were involved, today, but I remember that the print out was done so we could keep track of what was happening as no one on the project could just remember everything off the top.

Jim

----- Original Message -----
From: "Arthur Fuller" <fuller.artful at gmail.com>
To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com>
Sent: Tuesday, May 6, 2014 8:42:48 AM
Subject: Re: [AccessD] Should Business use Access?

Jim Hewson (not Lawrence),
An Access app consisting of 72 tables is not a complex app. First of all,
we need two better words than "complex". I suggest "Rich" and "Large",
whose terms I think I inherited from Chris Date, but it might have been
Fabian Pascal, or even the Father of Us All, Codd (in close company I call
him The Coddfather).

History aside, I would describe a complex app as consisting of at least 500
tables, and there goes one of the main reasons why Access int its packaged
version falls a tad short of the mark. In specific terms, the Relationships
tool is woefully inadequate even with 55 tables, let alone 500. That's when
you need SSMS or equivalent tools -- when you need 10 relationship diagrams
not one, and when you need to concentrate on one aspect of the app rather
than the whole app, and that one aspect might involve 100 tables. This is
especially important when the team involves several programmers, and also
when developers die or retire, and new hires have to be brought up to speed.

I neglected to define the terms Rich and Large. Rich means there are
hundreds of tables, many of which have a relatively few rows. Large means
they are relatively few tables, but they contain millions of rows. It is
also possible that a given database is both Rich and Large, but that
happens rarely. Usually the system is one or the other. I've developed a
couple of exceptions, for example the software that runs a nuclear plant;
that is way different than an app for a Mom'n'Pop hardware store or a
household renovation firm. Suppose for example that you need 584 parts to
assemble Product XYZ, and that every single part is potentially available
from several vendors, and that you need to check who can supply 486 of
these parts by tomorrow. You need to interrogate their inventory, and
suppose that nobody has 486 parts, so you have to split the order and
ensure that the deliveries shall arrive in time to fill your orders. This
sort of problem is not trivial. Failure could conceivably cost $750k per
hour.

I've done a lot of apps like this. It's expensive, but the development time
is peanuts compared to the profit if it works. Such companies understand
this, and so do we developers. It has got to work, or millions could be
lost in a day of down-time. Working on such projects has cost me a couple
of marriages, because I was two days late for dinner.

I'm too old to this stuff any more, but I remain fully aware of how
difficult it is. There is definitely truth to the maxim that your thinking
slows as you age, and it is also true that a young buck just out of
university hasn't the faintest glimpse of the complexity of such problems,
or the costs of failure. In jobs like this, failure is not an option.

I have done this sort of app, using Access with a serious server using SQL
Server and also MySQL. 500 tables and dozens of forms and 2k stored
procedures and queries. This stuff is non-trivial. It demands a whole lot
of design time and a whole of development time. You do it one piece at a
time, starting with the most financially critical. The whole project takes
several years, which enables you to buy a nicer car and perhaps a new
couch. You work insane hours and eventually your spouse leaves you. That's
the truth.

A.
​
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com