[AccessD] Should Business use Access?

>> I would describe a complex app as consisting of at least 500 tables

The number of tables does not drive how complex an app is, it is the relationships of those tables and the queries used for them and the forms and controls and their respective recordsources and rowsources that make an application complex or simple.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, May 06, 2014 11:43 AM
To: Access Developers discussion and problem solving
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