Re: Surrogate Keys

David Cressey wrote:

> The biggest problem with ACCESS isn't that it's not client/server. The
> biggest problem is that it's not relational. It does an awfully good job of
> fooling the uninitiated that it is relational, and it almost is.

Here we go again! Joe says its not SQL and you say its not relational. Well, I must have been using it with my eyes closed! I seem to be able to to create relations with primary keys and foreign keys, and attributes. If my logical design is relational, Access seems to be able to cope with it just fine.

As for SQL, I am happily creating bog-standard SQL statements which it handles perfectly either in the RDBMS itself or via an ODBC connection.

SQL certainly isn't relational, but it was never intended to be (it can return denormalised results for one thing). All vendors have enhancements to their SQL which one can use or ignore. Generally I ignore them.

For a start, *no* 'relational database' adheres to the true relational algebra as described by Codd. Most get close enough for day to day use today. Access does a pretty good job as far as I can see. Can you give some examples where it will really hurt? I know things like it lets you create a table without a primary key - I never do that anyway.

Access has some major limitations. these are some I have found:

1 It is file based. What's worse is that is corrupts itself too easily. Successive version have improved this situation (I haven't used 2000), but its still a problem to be managed
2 It is slow when used over a reasonably sized lan. Much effort is needed to optimize even a small db (say 15Mb) to run with several simultaneous users. 3 It doesn't do stored procedures. This is a real problem for people who don't like to design databases which adhere to the rules (Codd's).The most frequent use of SPs is to 'fix it in the mix'. As you see, I don't know if this lack (of stored procedures) is a good or bad thing. Comment invited. 4 Perhaps very high on the list is its inability to define sensible intra or extra table constraints. this is probably an extension of the stored procedures issue.
5 Finally, it doesn't do security apart from table level. It really needs column level (row-level would be nice too)

There. I have made a statement about Access ('Access has some major limitations') and justified it. Why can't you guys justify your carelessly issued condemnations of a product?

So why do I use it? Joe said it. Its there and already paid for. But it also has some fairly useful tools to build databases quickly. And it has alot of books, tutorials, courses, and people who can work on it. And as as long as my design is good enough (I'm trying harder on this one:-) the Access implementation can be ported to any other database without too much bother.

So, David, I am the fooled uninitiated Access developer. Please enlighten me as to why. You might be right, but you have given no evidence. I normally ignore such crass statements but you caught me on a bad day (Access crashed :-)

Regards

Neil

>
>
> Having said that, I've used ACCESS a lot of times when I just wanted to do
> some quick and easy things to a moderate amount of data, and wouldn't be
> likely to get into trouble with its limitations. One of the
> features I like most about ACCESS is its crosstab queries, and this is, in
> fact, one of its non relational features.
>
> Neil Burnett wrote in message <393181F7.E43562CE_at_efc.be>...
> >That's a little harsh. Access is fine for many database applications. Its
> >not client/server, but many small applications don't benefit from that
> >anyway. Until one knows the scope of your application, it is difficult to
> >advise.
Received on Wed May 31 2000 - 00:00:00 CEST