[thelist] Access db X SQL
Darren
Darren at web-bitch.co.uk
Mon Aug 20 11:11:02 CDT 2001
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
More information about the thelist
mailing list