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.
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.
-
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.
"SIR", Where you sergeant in the military? "SIR"? :laugh: :laugh:
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.
-
"SIR", Where you sergeant in the military? "SIR"? :laugh: :laugh:
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.
Exactly, but I only needed that Sir! stuff during an exchange program with the Americans.
I have lived with several Zen masters - all of them were cats.
-
Exactly, but I only needed that Sir! stuff during an exchange program with the Americans.
I have lived with several Zen masters - all of them were cats.
I was always wondering if this was really as it is shown in some movies As per you answer... I guess so
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.
-
I was always wondering if this was really as it is shown in some movies As per you answer... I guess so
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.
That kind of stuff was reserved for basic training or special occasions when you intended to hold a monologue to someone (which then usually ended with 'Dismissed', meaning 'get out of my sight').
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.
This can happen for a number of reasons. I have seen this many times. From bad scripts, to some of MS data compare tools, etc. Hopefully you have the scripts handy, an you can just recreate the missing keys. :thumbsup:
-- rants are the vehicle of the lazy and uninspired - JSOP 2/2018
-
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
Last week I added a few fields to a table, no problem. Yesterday we got the data and I realized I needed to change the type of one field in said table as the data was a bit different than I had expected. No problem I think, we haven't added any data to that field yet, so I enter design mode, change the type and save the changes. Up comes a popup stating it cannot rewrite the table as there are several tables depending on it. No problems I think again, I cancel out of it and decide to change the table the next day using DDL instead. And today to my surprise I see that the table does not have any foreign keys anymore. Go figure. The takeaway is to not trust the designer mode of SSMS. <edit>I haven't tested it fully yet, but it seems like it might happen when you have an indexed view on the table
Wrong is evil and must be defeated. - Jeff Ello
-
Exactly, but I only needed that Sir! stuff during an exchange program with the Americans.
I have lived with several Zen masters - all of them were cats.
We like our formal modes of address, and have AR 600-20 to express how much we like it.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
We like our formal modes of address, and have AR 600-20 to express how much we like it.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Sure, but it's hard to stay formal all the time in a team you spend more time with than your family. Plus, that's that's a very fundamental matter, any regulations that smell like earth and are for the groundhogs would have applied to me. :-) Not that our regulations would have been so different.
I have lived with several Zen masters - all of them were cats.
-
Sure, but it's hard to stay formal all the time in a team you spend more time with than your family. Plus, that's that's a very fundamental matter, any regulations that smell like earth and are for the groundhogs would have applied to me. :-) Not that our regulations would have been so different.
I have lived with several Zen masters - all of them were cats.
I don't disagree per se, but I think that maintaining decorum is important. It's a question of discipline, especially when setting an example for the lower enlisted.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
I don't disagree per se, but I think that maintaining decorum is important. It's a question of discipline, especially when setting an example for the lower enlisted.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Absolutely, no question about that. I was in an air defense team and usually spent days in a row with training, maintainance and watching radar screens. On an alert we officially would have had 30 minutes to report ready, but anything over five minutes would have been a disgrace. And this time includes getting out of bed, running to your station, putting on whatever clothes you could grab and completing your system checks. You will not get such a time if you do everything by the book. It's not disrespect, there is just no time for formality and everyone is trained well and knows what he has to do. Sitting together afterwards and having something to eat and a chat is also perfectly normal. And there also is the traditional missile away party after six months of preparations, live firing and getting a good score. The commander happily pays for everything and for nothing in the world would miss that little party after all that work and in the end having looked good before an international team of testers.
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.
Well, I certainly hope you don't have a production application that relies on the existence of them for correct behaviour. :omg:
-
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.
I had an Enterprise Architect come to me and demand that all the FKs be dropped in the lower environments because it was causing issues. I, politely, suggested that maybe the code was wrong. That did not go over well. So then I told him that I didn't have the authority to do that so he would need to talk to my boss (my boss was a much more devoted FK adherent). They fought, my boss lost. So I dropped them. Less than a week later the test data was complete trash. At one point Texas was a province in Canada. There were many other examples, but that is the one that continues to stick with me to this day. When I showed them the bad data it was dismissed as just test data and that I shouldn't worry about it. There were other signs that this project was going to be a disaster so I transferred out. About four or five months later they went to production. Within ten days it had to be backed out of production. At this point I had been at this company for seven or eight years. In that entire time I had never heard of project going to production and then being backed out. It was a disaster. The executives had no stomach to spend the money it would take to get it working so they canned the project and let pretty much everyone on the project go. Which is a shame. There were some really good people who tried very hard to make it work, but the bumbling idiot E.A. was just too much to overcome.
-
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
