Cowboy (Gregory A. Beamer) said:
1. Access is a horrible platform for large databases. While it can get to
a rather large size, it is a file based DB, which means perf degrades
horribly.
Actually, in single user mode a JET based file application is faster then
sql
server. I am going to repeat this again just in case you think this was a
type-o. The JET engine is faster then sql server!!! Anywhere from 30 to
200% faster. Remember, sql server has a ton of
overhead, and JET simply scrapes data right off of the disk drive.
Further, you seem to imply that you don't have a choice of what data engine
to use. Remember, ms-access is just a ide. It is a ide like visual studio.
You write code, you build forms, you build class objects. The data engine
you use with ms-access can be JET, or it can be sq server. There are
companies
out there with 1000 simultaneous users of ms-access all hitting the SAME
database. The fact of the matter sql server runs no different if you code
in c++, or use ms-access (they both are using the same oleDB library).
You can scale the applications to 100's of users in all cases when you use
sql
server.
However, the fact remains that JET grabs records faster then sql
server (we taking same hardware....no network involved here). In fact, to
normally grab data from sql server you still (on a local host) have to grab
data through a socket connection, and that alone is going to slow things
down
(further, sql serve has to wrap most things in a transaction, and also use
timestamp
fields to ensure things are ATOMIC).
2. Access is great for single developers, but bad for team development. It
is difficult to impossible to get a team working on the same solution,
unless Access is merely a data repository.
Remember, the coding environment in ms-access is the same as VB6. You can
create calls objects in ms-access, and this does help in the re-usability
area. Also, Visual Source Safe also works with ms-access also. So, I am just
point out that ms-access is not a database at all, and all of the
development trappings such as using visual source safe etc does work with
ms-access. If you want to use VSS, and have users check in/ check out
code, the you can do so with ms-access. So, I think for this discussion
it
is impart to distinguish between the
database part, and the IDE that ms-access is.
The database part that you use with ms-access can be the file based JET
engine, or you can use sql server.
Having said the above, as a project does get larger, then coding approaches
used, and things like considering a 3 tried approach to the application does
favor using Visual studio, source code control, and a language like .net, or
even c++. However, to use c++ for writing a average business application
is kind like writing some calculations in assembler to add a few numbers
when you got Excel sitting on your desktop. However, for real-time fluid
calculations
that c, or assembler would be a good choice.
Note that the same arguments can be made
against VB6 in this regards of project size. So, yes, I do agree with you
that project size is most certainly a consideration here. I have to agree
that as a project scales to MANY developers, then the fact of reduced
development speed becomes less of a factor, and things like using a OO
approach in terms of design and modeling code most certainly does
become an advantage in other IDE's. (.net for example!!) However, it also
needs pointing out that the MAJORITY of bussing applications written today
do NOT HUGELY benefit form the large use of a OO approach. However,
more and more business applications do benefit from a general OO approach.
With
..net gaining traction in the marketplace, then the OO approach becomes more
common.
3. Access creates monolithic applications, which means there is little
flexibility in distributing the work as your company grows.
This is a interesting aspect. Virtually all ms-access developers now split
their
code/forms away from the data part. You create what is called a mde in
ms-access
(essentially a compiled version of the application). This means to update a
user, you simply send them the new mde, and they copy it over the old one
Since the application has no data..then this works great. In fact,
ms-access developers have enjoyed this x-copy development process for years.
You now hear today .net developers singing the praise of x-copy development.
I
just last week deployed a whole version of my software to 5 different
companies (and, they were in a different city then me!!). To deploy this new
software, all the users had to do was copy the application to their
computers..and away they went (I did wrap the mde in a Inno install..and
send them a .exe to run). However, this band new "singing" of the praise
by .net developers of how you can simply copy the application part to the
users
computer and it runs has been a feature, and part of the landscape for
ms-access developers for a long time. There is no question that many
arm-chair ms-access developers make the mistake of not splitting out the
code/forms/logic from the data, .but as a general rule, ms-access developers
do not keep the data part, and application part as one monolithic
application.
This decision is not the fault of the ms-access design, but that of the
developers using the product. So, while .net users sing the praise of x-copy
development and deployment...we had that great feature for years!
Access certainly fits a niche. It has a wonderful designer and allows you
to leverage your work with forms, queries, reports, etc. Much of the work
can be done without a huge amount of code. But, you pay a price, as you
lock yourself into the Access solution. If you later outgrow, you end up
rewriting everything.
The outgrow part you mention has to be defined here. Do you mean the data
part, or the application complex part? The data part is easy, you just move
the back end data part to Oracle, sql-server, or whatever your favorite
data
engine tends to be. The application part is a fair issue you bring up. Once
again, as a developer I do commonly now use, and built class objects in
ms-access. However, you can't use ms-access to build the middle tier in a 3
tiered applications (apparently, there is a com add in for ms-access..but I
don't think it is appropriate use here). And, ms-access does support xml,
and
also has the soap tool kit add-in. With the soap kit, ms-access can now
easily consume ..net services.
I have to say that the MAJORITY of small business applications written don't
need more
then a few developers. However, if the product you are crating is to be
widely distributed, and you want a reduction in dependencies, and you expect
to have a large development team, then ms-access is a weak choice. However,
it is VERY difficult to outgrow ms-access in terms of a large database
(since
you just move the data to a server based product).
Once again, I am not saying ms-access should be use for all projects. And,to
be fair, ms-access works well in a two tiered approach, but not much well in
a 3 tiered approach. However, again, if you only got 30 -200 users, then
a two tiered approach (ms-access/sql server back end), then sql server and
ms-access will hardly break out a sweat. For larger user counts, and
applications with larger amounts of business logic, then better environments
most certainly do exist then ms-access. The only question that remains is
when to choose what tools for the right job. As always, this is about the
right horse for the right course...
<g>