|
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.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
Is this an asset/liability management system, by chance?
|
|
|
|
|
txmrm wrote: with application issues caused by orphaned data
Then they're not testing properly. A production app should not rely on constraints.
|
|
|
|
|
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.
The discipline to insure they stay in sync, now just rests with the people and not the system.
Power to the people!!
|
|
|
|
|
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
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Got a drawer full of them.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
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.
-- rants are the vehicle of the lazy and uninspired - JSOP 2/2018
|
|
|
|
|
Well, I certainly hope you don't have a production application that relies on the existence of them for correct behaviour.
|
|
|
|
|
Your subject line upset me [until I read the message].
|
|
|
|