Saved And/Or NotSaved

thistooshallpass

There is a "design pattern" I've seen a few times in the past, and today I had the opportunity to see a very consistent implementation.

In the DAL:

public bool Saved { get; set; }
public bool NotSaved { get; set; }       
//public int NotSaved { get; set; }

The comment is important... for reasons that became clear once I checked the data model. (see below)

In the GUI:

private System.Windows.Forms.CheckBox notSaved;
private System.Windows.Forms.CheckBox saved;

// saved
this.saved.Name = "saved";
this.saved.Text = "Document was saved";
// notSaved
this.notSaved.Name = "notSaved";
this.notSaved.Text = "Document(s) was not saved";

Note: I actually took the time to check in the source repository to find where the "(s)" was coming from. It was added to the Text property almost two months after the previous commit to the file. The commit was made by some guy I never heard of, and after seeing this I noted his username so I could lookup more of his code whenever I'll be bored in the future.

The database offers the same design, but with a future-proof twist, using int instead of bit:

CREATE TABLE CX_DOCSTORPFTM_EVNT
(
[PDOCID] [decimal](15, 0) NOT NULL,
[RSRCDOC] [char](48) NOT NULL,
[PFTMSEVNTADDED] int NOT NULL,
[PFTMSEVNTNADDED] int NOT NULL, 
[PFTMSEVNTAUDT] datetime2 NOT NULL
)

I did not check in production, but in the QA environment there are quite a few records where (PFTMSEVNTADDED = PFTMSEVNTNADDED), and I did not see a single ticket for that issue.

Besides this design which I would dare call suboptimal, the application itself is beautiful, with overlapping gradients. Reminds me of Geocities, 1997.

The_Quiet_One

What, no schrodinger's paradox comments yet?

I am disappoint. :(

hoodaticus

Urge to kill, rising....

thistooshallpass

Yep, with this data model it is technically possible to have a document that is both Saved and Notsaved, or not Saved and not NotSaved. This makes the data model more powerful than boolean logic.

I reported what I figured what an issue but I was told that this is not a serious problem because of "slicing and dicing". According to the client's logic, the current model is okay because it can give him the Saved records, the NotSaved records, and the Saved or NotSaved records. Can't argue with that. And they thanked me for my valuable input.

PJH

@thistooshallpass said:

According to the client's logic, the current model is okay because it can give
him the Saved records, the NotSaved records, and the Saved or NotSaved records.

What about the unknown unknowns?

Xyro

@thistooshallpass said:

According to the client's logic, the current model is okay because it can give him the Saved records, the NotSaved records, and the Saved or NotSaved records.

Is the client Catholic, by any chance?

PJH

@Xyro said:

@thistooshallpass said:
According to the client's logic, the current model is okay because it can give him the Saved records, the NotSaved records, and the Saved or NotSaved records.
Is the client Catholic, by any chance?

Only if the records are younger than 18 years old would be my guess.

hoodaticus

@thistooshallpass said:

Yep, with this data model it is technically possible to have a document that is both Saved and Notsaved, or not Saved and not NotSaved.

This sounds a lot like a genuine theological argument.

thistooshallpass

@PJH said:

@thistooshallpass said:
According to the client's logic, the current model is okay because it can give
him the Saved records, the NotSaved records, and the Saved or NotSaved records.
What about the unknown unknowns?

Well don't get me started on unknows... it's another big WTF...

In data warehouse lingo, an "unkown" is a situation when a fact is linked to a dimension via a key that does not exist in the dimension (basically a violation of data integrity). This usually happens when dimensions are not designed to track history. As an example, if a salesman made a sale in 2010, then left the company in 2011, it is possible that this guy got removed from the salesman table, but management will want to include his sales info in 2010 yearly reports - under the salesman aggregation there will be a "unknown" entry where this guy's sales will be accounted for.

Not with my client... Because unknowns are "confusing" in Excel, they made the decision to filter out the unknowns via regular ETL jobs. Which is similar to deleting error messages from a log file. (There is no problem because I don't see problems).

ekolis

@hoodaticus said:

@thistooshallpass said:
Yep, with this data model it is technically possible to have a document that is both Saved and Notsaved, or not Saved and not NotSaved.
This sounds a lot like a genuine theological argument.

Jesus saves, Satan deletes... the Holy Spirit friggin' REFORMATS!

PJH

@thistooshallpass said:

Well don't get me started on unknows... it's another big WTF...

I was joking. I appears your clients aren't. It's worse than you/I first thought.....

RTapeLoadingError

@thistooshallpass said:

In data warehouse lingo, an "unkown" is a situation when a fact is linked to a dimension via a key that does not exist in the dimension (basically a violation of data integrity). This usually happens when dimensions are not designed to track history. As an example, if a salesman made a sale in 2010, then left the company in 2011, it is possible that this guy got removed from the salesman table, but management will want to include his sales info in 2010 yearly reports - under the salesman aggregation there will be a "unknown" entry where this guy's sales will be accounted for.

Not with my client... Because unknowns are "confusing" in Excel, they made the decision to filter out the unknowns via regular ETL jobs. Which is similar to deleting error messages from a log file. (There is no problem because I don't see problems).

It's sad and frightening that people who don't understand or care about referential integrity have the power to break it.

It's not as if the problem of "this guy has sales in the system but isn't a current employee" is one that mankind has failed to solve. It's not even difficult, costly or time-consuming to implement and maintain*.

*Obvious generalisation

tharpa

@Xyro said:

Is the client Catholic, by any chance?

Sounds more Protestant than Catholic. I've never heard a Catholic refer to being Saved.

Renan

@tharpa said:

@Xyro said:
Is the client Catholic, by any chance?

Sounds more Protestant than Catholic. I've never heard a Catholic refer to being Saved.

Being raised as a catholic, I can say I heard about salvation a lot. In every mass the priests said "it's our duty and our salvation" sometime during the transubstatiation.

Catholics and protestants may be saved, but it's the spiritists who really get persisted.

Matt_Westwood

@PJH said:

@thistooshallpass said:
According to the client's logic, the current model is okay because it can give
him the Saved records, the NotSaved records, and the Saved or NotSaved records.
What about the unknown unknowns?

What about FILE_NOT_FOUND?

Sorry but someone had to say it.

tharpa

@Renan said:

@tharpa said:
Sounds more Protestant than Catholic. I've never heard a Catholic refer to being Saved.

Being raised as a catholic, I can say I heard about salvation a lot. In every mass the priests said "it's our duty and our salvation" sometime during the transubstatiation.

Catholics and protestants may be saved, but it's the spiritists who really get persisted.

I was also raised Catholic. The word form "Salvation", perhaps, but seldom "Saved". Though I'm sure there are regional differences.