[thelist] Access db X SQL

[Darren]

On 20 August 2001 at 16:55:33, Flavia Silveira-Tarzwell (FayeC) <fayec at canada.com> wrote:

FSTF> Hi,

FSTF> Now that I have figured out the database relationship I have another
FSTF> question...

FSTF> Is it ok to use Access databases on the web or I should just convert
FSTF> them to SQL?

on small scale sites access runs fine, just don't expect it to run more
than a few concurrent queries...below is one of rudy's posts on the subject
from another list...he says it much better than me....

FSTF> If so can I convert the database and maintain the relationship created
FSTF> in Access?

ummm...i think so.  scaling up from access to sql server is supposed to
be relatively easy, not that i've had to do it.  yet!  at the worst you
can always recreate the tables and relationships in sql server...

hth

darren


<rudy's mail...>

On 01 July 2000 at 21:07:47, rudy limeback <r937 at interlog.com> wrote:

>> Can anyone comment as to where the shortfalls are in Access

rl> seems that the biggest shortfall is scalability

rl> access chokes if it has to handle more than X simultaneous queries --
rl> reports vary as to the size of X, anywhere from six to twenty

rl> please note that this is simultaneous queries, not simultaneous users

rl> you can have any number of simultaneous visitors on an ecommerce site, but
rl> they will be invisible until they actually do something -- reading a page,
rl> filling out a form, pulling out their wallets to get their credit card
rl> number, etc.

rl> even if they all hit "add to cart" or "browse next page" or "make purchase"
rl> buttons at exactly the same instant, the queries that they generate will
rl> come in staggered over time (such is the nature of internet packets)...
rl> maybe only milliseconds apart, but still staggered...

rl> access will attempt to handle queries simultaneously, that is to say, in a
rl> multithreaded fashion, starting another before the first is finished, right
rl> up until the point where it chokes

rl> do a bit of math

rl> if you expect 10,000 queries in an 8-hour period, that's approximately one
rl> every three seconds

rl> what are the odds that they will overlap, i.e. be simultaneous?

rl> if every query is in and out in under two seconds (a good rule of thumb
rl> goal for database optimization), you won't get any overlap at all, unless
rl> the 10,000 aren't distributed evenly over the 8-hour period

rl> so what you have to plan for is peaks, e.g. midday north america, when
rl> office workers do online shopping on their lunch hours, or evenings, when
rl> they've arrived home and have finished supper...

rl> and peaks is what scalability is all about

rl> of course, if you do expect thousands of queries per day (whoopee!) then i
rl> daresay you've got the volume to warrant a more, ahem, industrial strength
rl> database engine

rl> other than scalability, there doesn't seem to be any other serious
rl> "shortfall" in access -- okay, its sql is a bit out in left field, but it
rl> has all the functionality you need for just about any query, including
rl> outer joins and subselects

rl> access is a great database and shouldn't be discounted just because it
rl> won't run eBay


rl> rudy.limeback
rl> r937.com
rl> evolt.org