Separate PK in Jxn Tbl?

[Salad]

-CELKO- wrote:

Thank you. You made my point. I was only wrong on the non-English
speaking programmers. It doesn't appear to be a famous failure, more
like a internal problem exacerbated by management.

It is a good classic screw up, with blame for everyone!

1) ACCESS programmer builds desktop app on his own that looks good for
his immediate needs.

Obviously a dedicated person that takes some initiative.

2) Management sees the app and wants to deploy it all over the
company. Hey, why design anything new when we have it already?

Dilbert's pointy headed boss comes to the rescue.

3) ACCESS programmer claims it will deploy and and management believes
him.

The programmer is correct.

4) It does not scale, it does not interface with mainframe apps,
external apps, etc. It has no documentation, etc.

Management decides unwisely to not spend money to upgrade it or redefine
it to meet goals. Programmer has a life and a job and doesn't have time
to write documentation. Mgt is too cheap to provide him with a
technical writer or someone to do bug testing. This is obviously not an
important project.

5) ACCESS programmer now has a career being the only guy who can keep
the sinking boat up. Never mind how many times a week it has to be re-
booted or how much data is lost.

Programmer skill level may come into play. Feature creep may come into
play. Management thought on project is nil. Something for nothing and
the chicks for free.

6) Neither the programmer nor management will scream for help and ask
for a budget. Management would look stupid; programmer would lose his
job and power

You get what you pay for.

I can't fault the programmer. He made something to make his job easier.
Mgt glommed onto it but wasn't willing to invest in it.

I asked before, are you on the committee that oversees the project? If
so, look in the mirror.

 

[Brian Selzer]

I think that if an application does some checking, it will also do some
enforcing.

I think you might have been aiming at something like the following:

The DBMS should always enforce the constraints that it can enforce, rather
than relying on applications to refrain from writing data that violates
the
constraints.

Note that the above is silent on what applications should or should not do
regarding constraints.

Yes.

 

[Bob Badour]

I'll go further than that. For most design problems there is more than one
acceptable solution. This is particularly true of schema design. Design
trade-offs will help determine which of two possible designs is better in
any given situation.

The key words on that paragraph are: design and tradeoff.

 

[James A. Fortune]

In that case, I believe they are wrong.

Access is way more likely than SQL Server to corrupt a primary key
field(s), especially when a large number of concurrent users are editing
under the same index value, perhaps while someone is also turning off
their computer without shutting down on a form bound to the same data.
It was a facetious consideration because that kind of corruption occurs
rarely in Access.

James A. Fortune
(e-mail address removed)

 

[James A. Fortune]

I think that application constraints and database constraints are
really
two entirely separate things. The fact that they may be structurally
identical obscures and confuses this point. (Hence Brian's entirely
reasonable rhetorical question above.)

What, indeed, is the point of having one application and not another
enforce a constraint, *if we view this from the perspective of the
requirements of the database* Clearly there is none. However
individual applications may have requirements that are best
implemented as constraints *within the application.* I call these
"application constraints" because they are specific to the
application. They are *not* integrity constraints, even if we
are using identical mechanisms (in different locations) for both.


Marshall

I think you're on to something. Making a distinction between database
constraints and application constraints helps me clarify my thinking.
Being able to "reflect" database constraints to keep applications in
synch with changes sounds like a great idea.

James A. Fortune
(e-mail address removed)