Re: Separate PK in Jxn Tbl?
Date: Thu, 31 Jan 2008 10:14:29 -0400
Message-ID: <47a1d7c6$0$4068$9a566e8b_at_news.aliant.net>
David Cressey wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:c4699a61-e76f-4ff3-aa25-310929b6ecc0_at_e10g2000prf.googlegroups.com...
>
>>On Jan 27, 2:18 pm, "Rick Brandt" <rickbran..._at_hotmail.com> wrote: >> >>>David Cressey wrote: >>> >>>>The idea of keeping garbage out of the database takes on an entirely >>>>different meaning if you are dealing with hundreds of programs >>>>written in COBOL, Java, or anything in between accessing a single >>>>Oracle database on the one hand. On the other hand, if you are a >>>>developer creating a self contained MS Access database cum >>>>application (tables, queries, forms, reports, modules, etc.) all in >>>>one file, the same issues arise, but they are resolved quite >>>>differently. >>> >>>>I'm not saying either one is "right" or "wrong". I'm just suggesting >>>>why an objection that makes perfect sense to you and me might be lost >>>>on the MS Access community. >>> >>> ^ >>> some of >>> >>>I think if a thorough poll was done it would show that the majority of >>>professional Access developers (those that make their living at it)
>
> would agree
>
>>>that data integrity rules should be enforced by the database engine
>
> wherever
>
>>>that is possible. >> >>Well thank goodness for that! For a scary moment I though Sylvian's >>views were representative of the access community as a whole, and that >>you guys didn't think that data integrity should be enforced primarily >>by the db engine. >> >> >>>The fact is that Access is a tool predominantly for *users*, not
>
> developers, and
>
>>>Microsoft appears determined with each subsequent version to make that
>
> more the
>
>>>case. The majority of changes make it easier to do things incorrectly
>
> because
>
>>>that makes the program easier to use for people who have no idea what
>
> they are
>
>>>doing. Since that group vastly outnumbers the other one can hardly
>
> argue with
>
>>>their logic from a business standpoint. >> >>My fear though is that many db developers cut their teeth using >>Access. If bad practices are encouraged just because access doesn't >>handle many concurent users, and tends to manage data where it's >>unlikely one will hit the pitfalls that artificial keys can lay, when >>developers graduate up to larger server systems they may well carry >>those mistakes on with them.
>
>
> I agree with you. However, we should keep in mind that the same arguments
> could be made about people learning bad programming habits by building
> amateur programs in BASIC, or bad website design habits by using a tool
> like Front Page.
Hmmmm... MS Access, MS Basic, MS Front Page... anyone notice a trend?
In general, the tools that require a very short learning
> curve encourage the belief that the longer learning curve is of no practical
> value.
It doesn't help when vendors, whose own employees know better, encourage life-long ignorance among their customers.
> We've seen that view voiced here (perhaps facetiously) by one of the Access
> MVPs. To the extent that he has acquired a lot of credibility with Access
> newbies, however acquired, if he gives advice that will become bad advice
> when scaled upward, he aggravates the pitfall you warn against.
>
> Elsewhere in the discussion, I opined that Access applications were
> generally stored in the same file as the database. I've heard enough
> contrary opinions to stand corrected on that score. (I can't find that part
> of the discussion anymore.)
>
> However, I still think that hundreds of DIFFERENT application programs
> accessing a single database and written by programmers who did not build the
> database, is qualitatively different from the design target of the people
> who write Access databases and applications.
Years ago, I heard that the median Access application used a single table with 500 rows. I wonder whether that has changed any.
> If they ever get to the point where the complexity of what they are doing
> matches the complexity of what practitioners using SQL Server, Oracle, or
> DB2 are doing, or the complexity that database theorists are addressing,
> they will be forced to either learn or disprove what some of us know, or
> think we know.
Access is a good end-user query tool. The problem is some are deluded into believing it should instead be a crappy application development tool or a piss-poor data management tool.
>>I certainly don't think developers should excuse sloppy RDBMS design >>just because they are using access (and of course I'm sure many of the >>professionals here wouldn't dream of doing so, despite others >>laxness).
>
> I have to admit that, when I'm just playing around, I engage in sloppy
> work. I would not go so far as to recommend sloppy habits as good ones in a
> newsgroup, however.
This is why, in spite of our many differences of opinion, you never seem to make my kill file. Your opinions and anecdotes are clearly designated as such and never passed off as the state of the art. Received on Thu Jan 31 2008 - 15:14:29 CET