CELKO (12/25/2014)
Please follow basic Netiquette and post the DDL we need to answer this.
I'm thinking you're a bit late with that on this one, Joe. 😉
Follow industry and ANSI/ISO standards in your data. You should follow ISO-11179 rules for naming data elements -- you have no idea.
This is probably not the fault of the original poster.
You should follow ISO-8601 rules for displaying temporal data.
Temporal data isn't required for this problem.
We need to know the data types, keys and constraints on the table.
Again, a bit late here. It's also not a "table". As the OP clearly stated, it's the result of a query.
Avoid dialect in favor of ANSI/ISO Standard SQL.
1. I don't often use the word but that's "Rubbish". A lot of the power of any given SQL Engine is in the extensions of the language. And true portability is a myth.
2. Where do you see any "dialect" being used in the original post?
And you probably need to read and download the PDF for:
https://www.simple-talk.com/books/sql-books/119-sql-code-smells/
Except for the "Status" column name, I'm curious what you see in the original post that would require such a reading especially considering that the OP probably didn't design the underlying tables.
What you posted is not a table! Duplicate rows, so you cannot have a key. A magic generic status, a email_something, etc. If this is a history, where is the temporal dimension? Please read this:
https://www.simple-talk.com/sql/t-sql-programming/state-transition-constraints/
Obviously you didn't read the original post where the OP clearly states "I have a sql query that returns the follow columns..." nor do you understand that the OP is trying to count the duplicates as a percentage of the whole. The OP has correctly returned just enough data to do what is being asked, although a bit of pre-aggregation would be a good first step to realize.
Merry Christmas, Joe! 😀
--Jeff Moden
Change is inevitable... Change for the better is not.