Cowboy (Gregory A. Beamer) said:
I would disagree with you on many points.
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. I would say 50MB is a good theoretical max, although I have seen
Access DBs in the ridiculous range.
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.
3. Access creates monolithic applications, which means there is little
flexibility in distributing the work as your company grows.
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.
I am not knocking Access, as it is a great product, but it definitely has
its limitations. Whether Jerome should use Access or not depends on his
final goal.
Lots of growth - Access as a backend only. Not wise to lock into to Access
forms.
Speed of getting product to market - Access may be the best option, if
Jerome is an Access developer
Application needs to scale - Access as backend, with plans on scaling data
up later (or MSDE from start)
There are other items to consider, of course.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***********************************************
Think outside the box!
***********************************************
1. "it is a file based DB"
You are talking specifically here about Jet databases. What you say is not
correct, I have live Access/Jet applications running just fine for years at
database sizes approaching 1Gb. Not a problem at all, you just need to
design 'em right. What IS ridiculous is your suggestion of a theoretical
maximum of 50Mb, and I cannot imagine what you base such a silly claim on.
Nonetheless, if you do expect to exceed the capabilities of a Jet database
(which is possible in many ways, not just in terms of size e.g. you may have
security/resilience requirements which Jet simply can't meet) then (as I
believe I mentioned) Access makes an excellent client to server database
engines such as SQL Server or Oracle.
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.
Sorry, you lost me here, it's perfectly straightforward to have different
people working on different front-end areas and then to integrate them.
3. "Access creates monolithic applications, which means there is little
flexibility in distributing the work as your company grows."
You are going to have to explain that one a bit better. Access as a client
to a server database engine is every bit as scalable as any two-tier
client-server architecture using the same database engine. You seem to be
stuck on Jet again.
4. "But, you pay a price, as you lock
yourself into the Access solution. If you later outgrow, you end up
rewriting everything."
See above re Access as a client to server database engines.
5. "I am not knocking Access, as it is a great product, but it definitely
has
its limitations. Whether Jerome should use Access or not depends on his
final goal"
Jet, whilst an excellent product for the right purpose, certainly does have
limitations. Access as a client to a server database engine is limited only
by the server (unless you are big enough to need a three-or-more-tier
architecture, or you are looking to distribute your app across the internet
which I already said Access is no good at).
6. "Not wise to lock into to Access forms."
How is that any less wise than locking in to, say, dotnet Windows Forms?
You've got to build your clients in something, and, as soon as you make that
decision, hey presto, you are locked in.
7. "Speed of getting product to market"
What's your point here? All other things being equal, a database
application will take, quite literally, a fraction of the time to develop in
Access as compared to Windows Forms in dotnet.