Cone of Uncertainty

Question

Cone of Uncertainty

Steve Jones - SSC Editor

SSC Guru

Points: 736212
More actions
October 26, 2022 at 12:00 am

#4101081

Comments posted to this topic are about the item Cone of Uncertainty

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

call.copse SSCoach Points: 18050 More actions · Answer 1

I like the way of thinking - not sure 70-80% covers it every time - think you've got to gauge depending on the customer. Some I've known have been nearer 5% 😉

roger.plowman SSChampion Points: 10265 More actions · Answer 2

Be wary when a user tells you "oh, we'll never need more than 1X of this. Or especially wary if they say "just 2X (or 3X" because it will inevitably become nX.

Or they say "this field will only ever contain 3 choices, we don't need a table to hold them". Yeah, table it is. And the supporting development to let the user edit it.

Or they say "the maximum size of this field can never exceed 10k. Uh-huh.

Oh, and if you're not the developer yourself please explain to them that dates always need to be sorted, have math performed on them, etc. so never store dates as strings. Also, it's a good idea to use Datetime with a date only constraint rather than just a Date type, because you never know when some bright-spark will demand a key field that was supposed to be date only suddenly needs to include time because "of course we told you it was never going to have more than 1 row per day, but company policy changed..."

Never design yourself into a corner because a little forethought now can save your sanity down the road!

Eric M Russell SSC Guru Points: 125561 More actions · Answer 3

There needs to be an abstraction layer between the application and the physical implementation of the database (tables and columns). Some will call for using web services or a microservices architecture, and that's a good foundation for developing applications - but the middle tier is still basically an application layer, and most of the time it's not owned by the DBA.

Many problems associated with refactoring can be avoided by leveraging stored procedures and views. If done correctly, even significant data modeling changes - like renaming tables or moving the PhoneNumber column from the Customer table to a new CustomerPhone table - can be implemented in a way that's transparent to the application.

Refactoring is a healthy part of the database life cycle. But an abstraction layer insures the application users and developers are not seeing or feeling the refactoring.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 4

+1 Million!

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)