 | |
#41
 
| |||
| |||
|
Re: Why is database integrity so impopular ? -
10-06-2008
, 09:16 AM
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#42
| |||
| |||
|
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#43
| |||
| |||
|
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#44
| |||
| |||
|
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#45
| |||
| |||
|
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#46
| |||
| |||
|
|
Hello Eric, On 5 oct, 20:30, eric.bouchardlefeb... (AT) gmail (DOT) com wrote: 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. I supose you are new in the position ;-) |
And as a developper, even when doing team OO programming, it was clear
that integrity was part of the database. This did not mean that
applications could not use their own integrity rules, it only meant
that the database was ultimately setting the rules. Additionaly, it
is now comon to see databases shared among many applications ... it's
therefore common sens to concentrate integrity at the data layer.
When I moved from a developper to a manager position, I had to work
with commercial applications I had not developped. Eventually - and I
guess it's everywhere the case - we had to share data from those
databases to new internally built applications. That's when I first
noticed poor data normalizations and complete absence of integrity.
Later on, errors at some ERP applications also put in evidence the
absence of integrity.
The strangest thing about this is the fact programmer use complex
RDBMS as a simple persistent data environemtn. If I had to developp
an application with all the integrity concentrated in the
application, I would use simple text files to store data. The result
would be the same in terms of security but I would obtain more
performance.
#47
| |||
| |||
|
|
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 |
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/>
#48
| |||
| |||
|
|
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 |
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/>
#49
| |||
| |||
|
|
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 |
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/>
#50
| |||
| |||
|
|
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 |
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/>
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.