What use are foreign keys anyway?
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Guess that guy couldn't relate :-\
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
And therein lies the value of forced auditing, saved outside the environment. Perhaps a block-chain on changes is needed... unless of course, the change is done from the 'sa' account and multiple people have access to the password.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I've experienced something like that once. For no reason, quite a few FK's had disappeared... I'm pretty certain no one on the team did it because we all knew the value of FK's. To this day I've seen it once and still can't explain it. My guess is that some external tool (comparer? EF? modeller?) removed them for some reason.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I've experienced something like that once. For no reason, quite a few FK's had disappeared... I'm pretty certain no one on the team did it because we all knew the value of FK's. To this day I've seen it once and still can't explain it. My guess is that some external tool (comparer? EF? modeller?) removed them for some reason.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I'm pretty certain no one on the team did it because we all knew the value of FK's.
Since "everyone knows it", no one would admit not knowing.
Wrong is evil and must be defeated. - Jeff Ello
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
for some unknown reason
It's always the same reason: Some dimwit tries to insert or delete something and bounces off these foreign key constraints. Instead of adapting the application logic to take the constraints into account, the harebrain throws the constraints (and the database's integrity) out the window. And what will they say when you ask them which part of 'referential integrity' they did not understand? (Offended whine): "But it works (*)!" (*) In there limited little world that means that the error message is gone, nothing more.
I have lived with several Zen masters - all of them were cats.
-
Rob Grainger wrote:
for some unknown reason
It's always the same reason: Some dimwit tries to insert or delete something and bounces off these foreign key constraints. Instead of adapting the application logic to take the constraints into account, the harebrain throws the constraints (and the database's integrity) out the window. And what will they say when you ask them which part of 'referential integrity' they did not understand? (Offended whine): "But it works (*)!" (*) In there limited little world that means that the error message is gone, nothing more.
I have lived with several Zen masters - all of them were cats.
CodeWraith wrote:
Some dimwit tries to insert or delete something and bounces off these foreign key constraints. Instead of adapting the application logic to take the constraints into account, the harebrain throws the constraints (and the database's integrity) out the window.
First job out of college, I was that dimwit Jr Developer. We needed to delete a few items and add a few new ones. You guessed it, I ran into the constraints. So I asked the Sr. Dev, he said to drop the keys, add and remove the items, then re-add the keys. Being a good student, I followed his advice. At least I was smart enough to use the automated generate Drop/Add script functionality in SQL so I didn't screw it up THAT much. Learning through mistakes.
-
CodeWraith wrote:
Some dimwit tries to insert or delete something and bounces off these foreign key constraints. Instead of adapting the application logic to take the constraints into account, the harebrain throws the constraints (and the database's integrity) out the window.
First job out of college, I was that dimwit Jr Developer. We needed to delete a few items and add a few new ones. You guessed it, I ran into the constraints. So I asked the Sr. Dev, he said to drop the keys, add and remove the items, then re-add the keys. Being a good student, I followed his advice. At least I was smart enough to use the automated generate Drop/Add script functionality in SQL so I didn't screw it up THAT much. Learning through mistakes.
I can certainly forgive a junior, but also would make him repair the database and then scrub the courtyard with a toothbrush. Some old habits die hard. The real horror are those who never learn and do this whenever they feel like it.
I have lived with several Zen masters - all of them were cats.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Trust me, it could be worse. My company sells a very large application using a SQL Server database. There are over 1500 tables in the database. You can count the number of defined FK relations on one hand and I suspect those were added by mistake. I have brought this up several times and it's always the same answer. We don't need no stinking FK relations in the database - the application code handles all of that. Of course, the poor support people constantly have to deal with application issues caused by orphaned data, etc.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Are you saying that they removed a column from an associated table? (Very bad) Or are you saying they removed the foreign key constraint from the associated table's matching column? (not as bad). The relationships are still there even without the strict foreign key constraint. They are not just a bit more philosophical. :rolleyes: The discipline to insure they stay in sync, now just rests with the people and not the system. Power to the people!! :laugh:
-
Trust me, it could be worse. My company sells a very large application using a SQL Server database. There are over 1500 tables in the database. You can count the number of defined FK relations on one hand and I suspect those were added by mistake. I have brought this up several times and it's always the same answer. We don't need no stinking FK relations in the database - the application code handles all of that. Of course, the poor support people constantly have to deal with application issues caused by orphaned data, etc.
Believe it or not, when I first started here, the majority of tables didn't even have primary keys, let alone foreign keys. It's been getting incrementally better since then.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason.
"This is an unsupported version. You're elephanted due to stupidity. Do not pass 'start' and jump of the nearest building to hide your tracks." I've become good at descriptive exception-texts :rolleyes:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
That someone could have been fan of No SQL world and sees relationship as spaghetti code
// ♫ 99 little bugs in the code, // 99 bugs in the code // We fix a bug, compile it again // 101 little bugs in the code ♫
Tell your manager, while you code: "good, cheap or fast: pick two. "
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
On my own projects I always script my datatabase into an SQL file and save it into subversion along with my source code. Any changes can be found in the svn log afterwards, works great.
Wout
-
A colleague today asked me to show him the database structure for an application I wrote a couple of years ago, for maintenance purposes. I directed him to the database diagram I had helpfully created in SQL Server. Sadly, upon opening it, it became apparent that someone had for some unknown reason decided to remove all the relationships between all the tables, for no obvious reason. I despair sometimes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Trust me, it could be worse. My company sells a very large application using a SQL Server database. There are over 1500 tables in the database. You can count the number of defined FK relations on one hand and I suspect those were added by mistake. I have brought this up several times and it's always the same answer. We don't need no stinking FK relations in the database - the application code handles all of that. Of course, the poor support people constantly have to deal with application issues caused by orphaned data, etc.
txmrm wrote:
There are over 1500 tables in the database.
Let me guess. They are named like "AGC1", "RCV32", etc? I worked with business logic once, and got to look at the tables behind BPCS. F me, what a clusterF. I once created an engineering change notice database which tracked changes to BOMs, and said which notice was on which person's desk, when they were due, which ones were associated with which project, etc. With the BOM table, there were only 32 tables in total. And some of them were just work tables which were repopulated via queries. 1500? Sounds like terribly engineered insanity!
-
That someone could have been fan of No SQL world and sees relationship as spaghetti code
// ♫ 99 little bugs in the code, // 99 bugs in the code // We fix a bug, compile it again // 101 little bugs in the code ♫
Tell your manager, while you code: "good, cheap or fast: pick two. "
Or as a tight-coupling to a specific storage paradigm.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
I can certainly forgive a junior, but also would make him repair the database and then scrub the courtyard with a toothbrush. Some old habits die hard. The real horror are those who never learn and do this whenever they feel like it.
I have lived with several Zen masters - all of them were cats.
In this case I would say the Sr. Dev should repair it. Since the Jr Dev was following instructions. Another thing would be if the Jr. Dev. just did it because he/she is smarter than the Sr. Dev.
CodeWraith wrote:
Some old habits die hard.
It is like smoking, the best... not to start ;)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
In this case I would say the Sr. Dev should repair it. Since the Jr Dev was following instructions. Another thing would be if the Jr. Dev. just did it because he/she is smarter than the Sr. Dev.
CodeWraith wrote:
Some old habits die hard.
It is like smoking, the best... not to start ;)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Now that you remind me... I forgot to insist on the first and the last words when anyone addresses me should be 'sir'. Another one of those old habits.
I have lived with several Zen masters - all of them were cats.
