What use are foreign keys anyway?
-
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
-
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.
Bloody foreign keys, coming over here, taking indexes away from native keys! Get rid of them all!
veni bibi saltavi
-
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.
We won't be able to use them after Brexit anyway.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Sander Rossel (sort of) wrote:
My guess is that some external tool removed them for some reason.
That's a pretty harsh way to refer to a contractor.
That's actually pretty kind compared to what I usually call them :) I'm a contractor by the way :laugh:
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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 was brought in to "improve" a system that had horrible performance. They were not sure why... It was an Industry Product that had been around for decades. One of their (20+) Goals: When creating a new XXX, have it take 90 seconds or less to add a new blank row to the grid that the user can then edit. Currently taking 4 minutes on average. Of course, my first assumption was "What type of grid, and how many rows..." Then I got access to the DB... They were, in fact, PROUD of not having ANY FK relationships. In fact, they had leaned away from INDEXING as space wasting... Of course, I considered NOT having them as TIME WASTING (per user, for every user)... They had plenty of space to waste... Upon reviewing the slowest requests, 80% were fixed simply by indexing things properly. They still refused to declare FK relationships (because good data should be avoided at all costs!)... Oh, and the company had NO IDEA why they were so slow. It literally took someone else (us) to look at their system and ask a few questions... Nobody thought it could be the DB, because it was fast for everyone else... (all much smaller companies). Ughhh...
-
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.
Is this an asset/liability management system, by chance?
-
I was brought in to "improve" a system that had horrible performance. They were not sure why... It was an Industry Product that had been around for decades. One of their (20+) Goals: When creating a new XXX, have it take 90 seconds or less to add a new blank row to the grid that the user can then edit. Currently taking 4 minutes on average. Of course, my first assumption was "What type of grid, and how many rows..." Then I got access to the DB... They were, in fact, PROUD of not having ANY FK relationships. In fact, they had leaned away from INDEXING as space wasting... Of course, I considered NOT having them as TIME WASTING (per user, for every user)... They had plenty of space to waste... Upon reviewing the slowest requests, 80% were fixed simply by indexing things properly. They still refused to declare FK relationships (because good data should be avoided at all costs!)... Oh, and the company had NO IDEA why they were so slow. It literally took someone else (us) to look at their system and ask a few questions... Nobody thought it could be the DB, because it was fast for everyone else... (all much smaller companies). Ughhh...
That sounds horribly familiar.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
We won't be able to use them after Brexit anyway.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Bloody foreigners, sending their brightest and best keys over here to...
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I was brought in to "improve" a system that had horrible performance. They were not sure why... It was an Industry Product that had been around for decades. One of their (20+) Goals: When creating a new XXX, have it take 90 seconds or less to add a new blank row to the grid that the user can then edit. Currently taking 4 minutes on average. Of course, my first assumption was "What type of grid, and how many rows..." Then I got access to the DB... They were, in fact, PROUD of not having ANY FK relationships. In fact, they had leaned away from INDEXING as space wasting... Of course, I considered NOT having them as TIME WASTING (per user, for every user)... They had plenty of space to waste... Upon reviewing the slowest requests, 80% were fixed simply by indexing things properly. They still refused to declare FK relationships (because good data should be avoided at all costs!)... Oh, and the company had NO IDEA why they were so slow. It literally took someone else (us) to look at their system and ask a few questions... Nobody thought it could be the DB, because it was fast for everyone else... (all much smaller companies). Ughhh...
-
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.
Haha.. this is funny - not! I've come across this all the time. The problem "back then" were application designers that had no idea, zilch, nada; about database structures. Yet, here we are in 2018 and I still see the same mistakes. Primary key every table with an auto-fill ID column. Yes, you have a primary key, congratulations! But what's the point if you don't have a reference to the ID from another table? Did someone forget that the ID Primary Key column is a machine necessity, if at all? Like who care my next record starts with ID 2001!? A true Primary Key is one created based on data "snippets" off other columns in the table. Yeah baby... bring back Excel databases! :confused: :rolleyes: Just do what I do when databases have no relations... DROP DATABASE.. oh but don't forget to save your data first. :-O
-
Haha.. this is funny - not! I've come across this all the time. The problem "back then" were application designers that had no idea, zilch, nada; about database structures. Yet, here we are in 2018 and I still see the same mistakes. Primary key every table with an auto-fill ID column. Yes, you have a primary key, congratulations! But what's the point if you don't have a reference to the ID from another table? Did someone forget that the ID Primary Key column is a machine necessity, if at all? Like who care my next record starts with ID 2001!? A true Primary Key is one created based on data "snippets" off other columns in the table. Yeah baby... bring back Excel databases! :confused: :rolleyes: Just do what I do when databases have no relations... DROP DATABASE.. oh but don't forget to save your data first. :-O
Fandango90 wrote:
A true Primary Key is one created based on data "snippets" off other columns in the table.
The "natural vs surrogate primary key" debate is like tabs vs spaces - some people insist that there's only one "correct" way to do, whilst others make a decision on a case-by-case basis. :) SQL Server: Natural Key Verses Surrogate Key — DatabaseJournal.com[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
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
When I have that problem, I rename the column with a suffix of "_DELETE" and create a new column with the old name and newly desired characteristics. The designer will let me do that without dropping and recreating the table. After I have migrated any data and updated any involved stored procedures and entity framework models, I delete the old column.
-
When I have that problem, I rename the column with a suffix of "_DELETE" and create a new column with the old name and newly desired characteristics. The designer will let me do that without dropping and recreating the table. After I have migrated any data and updated any involved stored procedures and entity framework models, I delete the old column.
I simply don't use the designer any more.
Wrong is evil and must be defeated. - Jeff Ello
-
Haha.. this is funny - not! I've come across this all the time. The problem "back then" were application designers that had no idea, zilch, nada; about database structures. Yet, here we are in 2018 and I still see the same mistakes. Primary key every table with an auto-fill ID column. Yes, you have a primary key, congratulations! But what's the point if you don't have a reference to the ID from another table? Did someone forget that the ID Primary Key column is a machine necessity, if at all? Like who care my next record starts with ID 2001!? A true Primary Key is one created based on data "snippets" off other columns in the table. Yeah baby... bring back Excel databases! :confused: :rolleyes: Just do what I do when databases have no relations... DROP DATABASE.. oh but don't forget to save your data first. :-O
Fandango90 wrote:
the same mistakes. Primary key every table with an auto-fill ID column
Sorry, I don't see how this is a mistake. :confused:
Fandango90 wrote:
Yes, you have a primary key, congratulations! But what's the point if you don't have a reference to the ID from another table?
I think you may have misunderstood the OP's issue. They didn't de-normalize, only removed the FK constraints.
Fandango90 wrote:
Did someone forget that the ID Primary Key column is a machine necessity, if at all? Like who care my next record starts with ID 2001!?
I'm not even sure what you mean by 'machine necessity'. Perhaps it's sarcasm and I'm not getting it. :confused:
Fandango90 wrote:
A true Primary Key is one created based on data "snippets" off other columns in the table
Again, I can't tell if this is sarcasm or a real opinion. :confused: So an identity or guid is not a true PK, but a couple of columns where one or more values can change is??? (or, just throw in a timestamp to be sure!) It sure makes future record maintenance a lot easier when I can tag a record with a single condition. Anyway, it would probably make an interesting poll. :)
"Go forth into the source" - Neal Morse
-
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.
Be careful of the "Script To..." option. Pay Attention to What "Script...To" Generates[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Fandango90 wrote:
the same mistakes. Primary key every table with an auto-fill ID column
Sorry, I don't see how this is a mistake. :confused:
Fandango90 wrote:
Yes, you have a primary key, congratulations! But what's the point if you don't have a reference to the ID from another table?
I think you may have misunderstood the OP's issue. They didn't de-normalize, only removed the FK constraints.
Fandango90 wrote:
Did someone forget that the ID Primary Key column is a machine necessity, if at all? Like who care my next record starts with ID 2001!?
I'm not even sure what you mean by 'machine necessity'. Perhaps it's sarcasm and I'm not getting it. :confused:
Fandango90 wrote:
A true Primary Key is one created based on data "snippets" off other columns in the table
Again, I can't tell if this is sarcasm or a real opinion. :confused: So an identity or guid is not a true PK, but a couple of columns where one or more values can change is??? (or, just throw in a timestamp to be sure!) It sure makes future record maintenance a lot easier when I can tag a record with a single condition. Anyway, it would probably make an interesting poll. :)
"Go forth into the source" - Neal Morse
A relation may have multiple candidate keys, any one of which may be selected as primary key. Any attribute that is subject to mutation is not suitable - because they simply cannot be used to identify a row. The "A true PK is one created on data "snippets" off other columns in the table" is explicitly the wrong way round in terms of normalisation. Every other column should be dependent on the whole of every candidate key, and have no dependencies on anything else. Here, Fandango seems to be proposing exactly the opposite - having the PK dependent on every other column, which is pure insanity, and worthy of an entry in this forum all by itself ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
