Why is database integrity so impopular ?

#**311**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**312**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**313**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**314**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**315**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**316**

On Nov 1, 8:57 am, "Walter Mitty" <wami... (AT) verizon (DOT) net> wrote:

Quote:

patrick... (AT) yahoo (DOT) com> wrote in message

news:fab13a41-6c86-45fc-9cf2-88c74e9c338a (AT) i20g2000prf (DOT) googlegroups.com...

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.

I think you might have meant "the relational data model" where you wrote
"relational database theory". True?

Could you give an example?

If you design part of your database to be relational, and another part to be
something else that's not conformant to relational, how do you use data
from the two parts together in an integrated fashion? Or is that too much
to ask?

This is probably where I proposed ditching relational theory
inadvertently. I think there is a role for relational theory, just
because I'm not immersed into it at the level others are doesn't mean
I'm telling _them_ to ditch it.

I'm saying that I could think of cases where I would avoid relational
technology for particular benefits, chiefly in terms of certain costs
of running it.

#**317**

On Oct 5, 11:30*am, eric.bouchardlefeb... (AT) gmail (DOT) com wrote:

Quote:

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.

Just to be difficult.....

This is now a long thread, with numerous well-crafted arguments
exhaustively
defending good database design. But (largely for the sake of
argument)
there are times when bad design is called for.

For large, well-funded projects, performance can always
be purchased, usually for far less than the maintenance costs
associated with
bad design.

But smaller, not-so-well funded systems are part of the bell curve
too.
I wrote a web-based administration system for an "outfitters"
organization once.
There were about 1000 licensed outfitters that needed to be tracked
by a single-person administrator. So there was a private interface
plus a
public one. The public interface was supposed to
include a keyword search that combined outfitter location with
arbitrary
combinations of attribute keywords like "elk hunting, fly fishing,
walleye, pheasant" etc.

This organization had a limited budget and insisted on
a cheap shared host server. Mysql queries with mulitiple named
cursors
ran like lightning on my desktop linux box, but they ran like half-
frozen molasses
on the overloaded shared host server.

But application code that did "string-like" over a long string of
comma-separated
keywords worked, and it ran an order of magnitude faster (on the
chintzy shared
host).

#**318**

On Oct 5, 11:30*am, eric.bouchardlefeb... (AT) gmail (DOT) com wrote:

Quote:

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.

Just to be difficult.....

This is now a long thread, with numerous well-crafted arguments
exhaustively
defending good database design. But (largely for the sake of
argument)
there are times when bad design is called for.

For large, well-funded projects, performance can always
be purchased, usually for far less than the maintenance costs
associated with
bad design.

But smaller, not-so-well funded systems are part of the bell curve
too.
I wrote a web-based administration system for an "outfitters"
organization once.
There were about 1000 licensed outfitters that needed to be tracked
by a single-person administrator. So there was a private interface
plus a
public one. The public interface was supposed to
include a keyword search that combined outfitter location with
arbitrary
combinations of attribute keywords like "elk hunting, fly fishing,
walleye, pheasant" etc.

This organization had a limited budget and insisted on
a cheap shared host server. Mysql queries with mulitiple named
cursors
ran like lightning on my desktop linux box, but they ran like half-
frozen molasses
on the overloaded shared host server.

But application code that did "string-like" over a long string of
comma-separated
keywords worked, and it ran an order of magnitude faster (on the
chintzy shared
host).

#**319**

On Oct 5, 11:30*am, eric.bouchardlefeb... (AT) gmail (DOT) com wrote:

Quote:

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.

Just to be difficult.....

This is now a long thread, with numerous well-crafted arguments
exhaustively
defending good database design. But (largely for the sake of
argument)
there are times when bad design is called for.

For large, well-funded projects, performance can always
be purchased, usually for far less than the maintenance costs
associated with
bad design.

But smaller, not-so-well funded systems are part of the bell curve
too.
I wrote a web-based administration system for an "outfitters"
organization once.
There were about 1000 licensed outfitters that needed to be tracked
by a single-person administrator. So there was a private interface
plus a
public one. The public interface was supposed to
include a keyword search that combined outfitter location with
arbitrary
combinations of attribute keywords like "elk hunting, fly fishing,
walleye, pheasant" etc.

This organization had a limited budget and insisted on
a cheap shared host server. Mysql queries with mulitiple named
cursors
ran like lightning on my desktop linux box, but they ran like half-
frozen molasses
on the overloaded shared host server.

But application code that did "string-like" over a long string of
comma-separated
keywords worked, and it ran an order of magnitude faster (on the
chintzy shared
host).

#**320**

On Oct 5, 11:30*am, eric.bouchardlefeb... (AT) gmail (DOT) com wrote:

Quote:

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.

Just to be difficult.....

This is now a long thread, with numerous well-crafted arguments
exhaustively
defending good database design. But (largely for the sake of
argument)
there are times when bad design is called for.

For large, well-funded projects, performance can always
be purchased, usually for far less than the maintenance costs
associated with
bad design.

But smaller, not-so-well funded systems are part of the bell curve
too.
I wrote a web-based administration system for an "outfitters"
organization once.
There were about 1000 licensed outfitters that needed to be tracked
by a single-person administrator. So there was a private interface
plus a
public one. The public interface was supposed to
include a keyword search that combined outfitter location with
arbitrary
combinations of attribute keywords like "elk hunting, fly fishing,
walleye, pheasant" etc.

This organization had a limited budget and insisted on
a cheap shared host server. Mysql queries with mulitiple named
cursors
ran like lightning on my desktop linux box, but they ran like half-
frozen molasses
on the overloaded shared host server.

But application code that did "string-like" over a long string of
comma-separated
keywords worked, and it ran an order of magnitude faster (on the
chintzy shared
host).