Re: Why is database integrity so impopular ?



On Oct 31, 5:07 pm, paul c <toledobythe...@xxxxxxxx> wrote:
patrick...@xxxxxxxxx wrote:
On Oct 6, 12:51 pm, Daniel Pitts
<newsgroup.spamfil...@xxxxxxxxxxxxxxxxxxx> wrote:
eric.bouchardlefeb...@xxxxxxxxx wrote:
Hello,
When time comes to build transactional databases (as opposed to data
wharehouses), I belong to the school that STRONGLY believe in
normalizing data with high integrity mechanisms. I know all the
performance cons but IMHO, pros largely overwhelme.
It amazes me, though, how many systems rely on the application to
manage data integrity. I work as IT director for a large-size
manufacturer and *none* of our applications use integrity. And I am
talking here of ERP and other mission-critical systems.
In fact, I had rarely open a database properly normalized and
inforced ... and I have been working with databases for over 10 years,
mostly in sectors where lack of integrity can result in dramatic
consequences.
What is wrong with modern DB design approaches? And what's the point
of using a big relational DB without the benefits of integrity and
normalization?
Thank you,
EBL
I think that part of the problem is DB design and Application design are
really different types of abstraction. For application programmers,
dealing with DB constraints is tedious.

The truth is that whenever your "Application" calls for persistence, it
is no longer just an "Application"; it has become a "System". System
design is a higher level abstraction.

Moving from Application design to System design is /almost/ a natural
progression, and many engineers traverse the barrier without ever
realizing and without learning the other aspects of System design. This
includes learning proper DB design.

I admit that I fell into that category for some time. My background has
been Application design, but I've started to appreciate the concept of
constraints at ever level of the System. I even sometimes wish that the
DB could do more validation than it does, even if it makes things a
little more "tedious". In this case, tedious just means the hard
problem is already solved.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

I think that relational database theory is too limitting for some
applications. I believe that the modern database needs to be split
into component parts so that not everyone has to be saddled with the
relational part.

No offence, but I think you are way off-base to associate any version of
the rm as being aimed at transactions in any way, neither theory (that's
being charitable as much of the transaction writing has no formal
theory) has much connection with other, at least so far. Suspect such
thought has to do with marketing bumpf from various product publicizers,
indoctrination seems to be involved. Still, I must say that a
declarative model of some version of transaction interests me though
I've never seen anybody try to explain one. But so far, you haven't
even hinted at that notion as far as I can tell. I think the happy
cirsumstance is all-important when trying to transpose one technique to
a new purpose and the first insight must be to recognize the circumstance.


Maybe the A of ACID. For instance, what would I use if I want every
record to store or none, but otherwise wasn't too picky? It could be a
filesystem question I guess.

Look at the web market for instance, every day I run across a web
application that has lost contact with its sql server way before the
webserver has lost contact with its visiting browser. I'm just saying,
sometimes you really want every clock cycle you can get and still want
atomicity of your persistance state (well, maybe could be just me). If
you don't think relational integrity of your data model burns oil then
maybe, but in that case, show me the money and the rdbms that I can
install on my very marginal rented webspace.
.



Relevant Pages

  • Re: Why is database integrity so impopular ?
    ... When time comes to build transactional databases (as opposed to data ... normalizing data with high integrity mechanisms. ... What is wrong with modern DB design approaches? ... I must say that a declarative model of some version of transaction interests me though I've never seen anybody try to explain one. ...
    (comp.databases.theory)
  • Re: Why is database integrity so impopular ?
    ... When time comes to build transactional databases (as opposed to data ... normalizing data with high integrity mechanisms. ... What is wrong with modern DB design approaches? ... I must say that a declarative model of some version of transaction interests me though I've never seen anybody try to explain one. ...
    (comp.databases.theory)
  • Re: Why is database integrity so impopular ?
    ... When time comes to build transactional databases (as opposed to data ... normalizing data with high integrity mechanisms. ... I think that part of the problem is DB design and Application design are really different types of abstraction. ...
    (comp.databases.theory)
  • Re: double-entry bookkeeping unneeded?
    ... I'm not asking you to design a system. ... that would represent the business transaction that I described above. ... usability problem described below. ...
    (comp.object)
  • Re: Session ending shutdown problem
    ... massively long shutdown time, you will have to rethink what it means to "shut down". ... and start routing everything to it instead of the databases. ... this process starts gets appended to the transaction file instead. ... Of course I can detect the QueryEndSession and EndSession messages. ...
    (microsoft.public.vc.mfc)