SQLServerCentral » Discuss content posted by R Glen Cooper » Mathematical Auditing Of Email BroadcastsInstantForum 2016-2 FinalSQLServerCentralhttps://www.sqlservercentral.com/Forums/SQLServerCentralTue, 17 Jan 2017 22:05:23 GMT20Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost721851.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Database+Mail/66775/">Mathematical Auditing Of Email Broadcasts</A>[/B]Tue, 20 Oct 2009 13:15:51 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost806028.aspxGlenn,
Thanks for the reply. I was just using that as an example. Of course, since they are within our mail system, there would be no problem. However, if I am the MarCom company trying to reach those people, the sales manager's boss could end up with two or three of the same email and the MarCom would not know it.
btw, on of your other responses pointed to the wolfram site. I had heard of mathamatica and we used it in gene research, but I had not heard of the web site. So I got two great things out of you post.
NickTue, 20 Oct 2009 13:15:51 GMTNicholas SteinRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost806010.aspxHi Nick,
Thank you for your response.
You are correct in that we have no way to see redirects in other email systems, so redirections from them to your own are possible.
I assume that your salesperson, sales manager, and his boss are using the same system so there shouldn't be an problem here (unless I'm confused about what you meant).
GlenTue, 20 Oct 2009 12:58:04 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost805972.aspxI love this article. DAGs seem to show up everywhere. I used them in a gene assembly program I wrote.
I am now working on groom email lists and this article is worth it's weight in platinum to me.
I do see a challange though. The redirects may not occur in an email system you have access to. If you send a broadcast to a group of customers, you will not see the redirects because they occur in the customer's email system.
At my former employer, when an employee quit, we made a redirect from the salesperson's mailbox to the sales manager's mailbox. When the sales manager quit, the redirect went to his boss.
So the question is how to track the redirects from the marketing communications company. I do not think you can.
I still loved the article though.
Nick Stein
nstein@bizcad.comTue, 20 Oct 2009 12:08:20 GMTNicholas SteinRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost734284.aspxThank you very much !!!
Best regards
Sat, 13 Jun 2009 03:00:41 GMTadrlinuxRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost731950.aspxThank you for the reply.
I can do this, but it will take a couple of weeks before I can get to it.
I will reply when it's done.
Glen CooperTue, 09 Jun 2009 17:24:08 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost731633.aspxHello,
Since this article is as interessing and usefull as "Ordering Tables To Preserve Referential Integrity" article, I ask the same question that I asked for the "Ordering Tables To Preserve Referential Integrity" article :
would it be possible to have the same script for sql server 2000 ? Badly I am not able to do the transformation (there is no Common Table Expressions in sql2000).
Thank you very much.
Tue, 09 Jun 2009 10:28:43 GMTadrlinuxRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost725584.aspxYes, that makes sense in that situation. If redirection, and not simply mailing lists that need to be expanded, then you could wind up with a circular reference like that that would be awkward and with no clean way to resolve it automatically.Thu, 28 May 2009 21:37:50 GMTtimothyawisemanRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost723726.aspxThat's an interesting reply.
I should have made a subtle distinction between mailing lists and re-directions. Although the latter may be viewed as a special case of the former, you can't delete someone's re-direction on the email server just because it causes conflicts elsewhere.
Suppose we have one broadcast submitted by Arnold:
A --> b
A --> c
and two re-directions submitted individually by Bob and Calvin (which you can't delete because these people don't want ANY emails):
b --> A
c --> b
Althoug A is a valid email address, it's meant to represent a mailing list (eg. customers@myCompany.com) while b, c are real people (eg. Bob@myCompany.com).
There are no duplicates in this list, but both circularity and redundancy exist.
We could remove the second re-direction, but then Calvin would start getting emails.
If we expand mailing lists on the right hand side, we would get:
A --> b
A --> c
b --> b
b --> c
c --> b
Eliminating self re-directions gets us:
A --> b
A --> c
b --> c
c --> b
Since we can't eliminate the last re-direction submitted individually by Calvin, how do we get rid of the duplicates on the right hand side? We could eliminate b --> c, but then Bob's now getting emails.
Already my head's spinning.
You may be correct in your approach, but it looks a bit messy (to me, anyway).
That's why I viewed these things as graphs, where mailing lists and re-directions are the same thing.
Tue, 26 May 2009 20:51:15 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost723694.aspxAwesome article and very interesting.
But it seems a simpler way of dealing with your problem is to change your e-mail broadcast system internally. Instead of the broadcast system every broadcasing to a list, have it expand all lists and remove all duplicates at the time it is sent. That way a broadcast list never receives anything from another internal broadcast list and no person ever receives a message twice. Am I missing something?Tue, 26 May 2009 18:01:07 GMTtimothyawisemanRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722301.aspxGood question.
Nothing automatic is done to resolve the issues, so that's worth investigating.
Fri, 22 May 2009 12:22:45 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722299.aspxThank you for the kind replies.
This work was motivated by a problem I had with a marketing company in Vancouver, where the database administrator was frequently interrupted by requests to fix their broadcasts. Although there weren't a lot of errors given the size of the weekly mailouts, each one was a serious annoyance that consumed a lot of time.
It took a while before I realized that their problems were simply anomalies in directed graphs, which made things easier to visualize.
But for really large graphs, we might need a more efficient way to process them.Fri, 22 May 2009 12:18:30 GMTGlen CooperRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722289.aspxVery interesting approach!
I'm not quite clear on the final practical step though-- do you avoid the multiple messages and circular references by making the person doing the mailing manually clean up their list, or could you solve the problem by resolving all distribution lists to their "final" addresses and selecting the distinct address?
BrianFri, 22 May 2009 12:01:43 GMTFeifarekRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722129.aspxVery well done.
A great example of practical math and DB tools.Fri, 22 May 2009 09:13:49 GMTJames RochezRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722124.aspxPhew........I didn't get the article ! ! ! May be I am week at Mathematical analytical.Fri, 22 May 2009 09:10:30 GMTSanjayAttrayRE: Mathematical Auditing Of Email Broadcastshttps://www.sqlservercentral.com/Forums/FindPost722043.aspx...are you working for http://www.wolframalpha.com/ !!!Fri, 22 May 2009 07:37:40 GMTDugi