|
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
|
|
|
|
|
I've seen this too, and know the reason. It's not a good reason, but it's a reason.
I'd designed and built a database with full referential integrity.
A team of programmers started to build a system around it.
Every time their code violated the rules, guess what? An exception was triggered! As intended. Imagine that.
It came to time to roll out the project. This meant deploying a fresh copy of the database to a production server. I used the same scripts that I'd written to deploy the development copy.
This resulted in a herd of coders arriving at my desk, all red in the face, and demanding that I use the copy on the development machine. It seems that between them, their understanding of error handling consisted of "on error goto", and they'd been so overwhelmed by the exceptions that the RI in the database caused, they'd removed all of it from the database. Seems my idiot boss saw no harm in giving them admin rights on the database server. Thankfully, he took my side when I explained to him why the project was going to be delayed!
So, if you're surrounded by idiots, then there's a reason why the RI was removed. It's not a good reason, but it's certainly a reason. Namely, you're surrounded by idiots.
|
|
|
|
|
How could such software go into production?
It's not correct by definition
No (acceptance) testing?
|
|
|
|
|
Sander Rossel wrote: No (acceptance) testing?
There is no testing, like testing in production!
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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"?
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.
|
|
|
|
|
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.
|
|
|
|
|
Ah, the good, old high volume one-way discussion.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Thank you for the heads up. Haven't run into that before, at least that I've ever noticed, but will start to check from now on.
I wonder what caused the line-breaks. To the best of my recollection it has always generated one line per statement, no matter the length of said line.
|
|
|
|
|
Yeah, that was the most weird thing I've seen in sql.
".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
|
|
|
|
|
Last year I finally got around to writing a utility that uses SMO with exactly the settings I insist on for generating scripts.
Things are so much more stable now.
|
|
|
|
|
Sad but true. I used to support such db at the start of my career
|
|
|
|
|
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.
|
|
|
|