3 added 20 characters in body
source | link

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

On top of that, trying to explore and understand the schema was very difficult. You could only guess at the columns that were intended to be foreign keys by the column's name and type. Schema diagramming tools don't work because they rely on foreign keys to map the relationships.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

On top of that, trying to explore and understand the schema was very difficult. You could only guess at the columns that were intended to be foreign keys by the column's name and type. Schema diagramming tools don't work because they rely on foreign keys to map the relationships.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

2 added 20 characters in body
source | link

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

1
source | link

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.