 | |
#251
 
| |||
| |||
|
Re: Why is database integrity so impopular ? -
10-31-2008
, 02:16 PM
|
Hello Eric, ... The problem is not in modern database theory, the problem is that most developers don't know the foundations of their profession and common sense is very uncommon. In my country most people who develop business systems never read a database theory book. The few ones who studied a database course in the university never understood database theory very well at all, and they forgot almost everything just on the end of the final examination. The textbook we used didn't have any chapter devoted to database integrity, only a few pages about the poor SQL declarative integrity support, and not covered with exercices. The whole Relational Model was dispatched in five hours or so, and taught with many mistakes and misconceptions. The vendor's training materials are usually even worse. And we also have all that abject oriented programming stuff saying that RDBMS's are nothing but silly and cumbersome register buckets. It is not only integrity and normalization. Most developers I know are not able to write non trivial queries and they load the data in the applications using simple queries, make several iterations on the registers, and send the data back to the DBMS. In the business software industry, technical incompetence is the norm, and the develpment tools we have are awful. Regards |
money to pay for the more expensive relational purists to implement
stuff. What the industry needs is to split up the database into
components so that implementers can decide how to persist their
applications. Sometimes you just want to write data reliably without
worrying about what normalization level you're at.
If and when a project needs fully relational recordkeeping, this
should be available too for those projects that can budget for it.
#252
| |||
| |||
|
|
Hello Eric, ... The problem is not in modern database theory, the problem is that most developers don't know the foundations of their profession and common sense is very uncommon. In my country most people who develop business systems never read a database theory book. The few ones who studied a database course in the university never understood database theory very well at all, and they forgot almost everything just on the end of the final examination. The textbook we used didn't have any chapter devoted to database integrity, only a few pages about the poor SQL declarative integrity support, and not covered with exercices. The whole Relational Model was dispatched in five hours or so, and taught with many mistakes and misconceptions. The vendor's training materials are usually even worse. And we also have all that abject oriented programming stuff saying that RDBMS's are nothing but silly and cumbersome register buckets. It is not only integrity and normalization. Most developers I know are not able to write non trivial queries and they load the data in the applications using simple queries, make several iterations on the registers, and send the data back to the DBMS. In the business software industry, technical incompetence is the norm, and the develpment tools we have are awful. Regards |
money to pay for the more expensive relational purists to implement
stuff. What the industry needs is to split up the database into
components so that implementers can decide how to persist their
applications. Sometimes you just want to write data reliably without
worrying about what normalization level you're at.
If and when a project needs fully relational recordkeeping, this
should be available too for those projects that can budget for it.
#253
| |||
| |||
|
|
Hello Eric, ... The problem is not in modern database theory, the problem is that most developers don't know the foundations of their profession and common sense is very uncommon. In my country most people who develop business systems never read a database theory book. The few ones who studied a database course in the university never understood database theory very well at all, and they forgot almost everything just on the end of the final examination. The textbook we used didn't have any chapter devoted to database integrity, only a few pages about the poor SQL declarative integrity support, and not covered with exercices. The whole Relational Model was dispatched in five hours or so, and taught with many mistakes and misconceptions. The vendor's training materials are usually even worse. And we also have all that abject oriented programming stuff saying that RDBMS's are nothing but silly and cumbersome register buckets. It is not only integrity and normalization. Most developers I know are not able to write non trivial queries and they load the data in the applications using simple queries, make several iterations on the registers, and send the data back to the DBMS. In the business software industry, technical incompetence is the norm, and the develpment tools we have are awful. Regards |
money to pay for the more expensive relational purists to implement
stuff. What the industry needs is to split up the database into
components so that implementers can decide how to persist their
applications. Sometimes you just want to write data reliably without
worrying about what normalization level you're at.
If and when a project needs fully relational recordkeeping, this
should be available too for those projects that can budget for it.
#254
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#255
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#256
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#257
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#258
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#259
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
#260
| |||
| |||
|
|
On Oct 6, 12:51 pm, Daniel Pitts newsgroup.spamfil... (AT) virtualinfinity (DOT) net> wrote: eric.bouchardlefeb... (AT) gmail (DOT) com 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. |
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.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.