Our Very Own SQL Server Data Compression
-
Comments posted here are about the content posted at temp
-
Nice little technique.
Reminds me of when I realised the power of of using
(col = @arg OR Len(@arg) = 0)
for only using passed values in joins when needed without cumbersom if-else statements or dynamic sql.
-
Nice article Steve. Just out of curiosity, how many e-mails do you currently send monthly?
-
North of 4million
-
I'm sort of surprised you didn't go one step further and make the MessageFrom, To, and Subject be IDs out to a separate table. There has got to be a LOT of redundancy there.
-
Subjects maybe, but the others aren't necessarily worth the join effort. From/to come from a table with lots of data as well. And this way the system can be easily split out to another database/server for scale reasons.
Plus we trim about every 7 days
-
I think at some point we'll incorporate subject, mainly because it will make producing things like newsletters easier. It's hard to know how far to take something, so far the simplicity of just appending the from/to/subject has worked for us. If we outgrow that, we'll change it! Nice to own your own code for stuff like that. Our solution is a deliberate attempt to build the simplest solution that would work for us, compared to what I consider the overkill of Notification Services. We just don't need all right now.
-
A captivating hands-on how-to article. Although I do not have a current need for such a large scale email system, I would not have thought that SQL Server would be a possible solution. I think it is a very innovative use. Thank you for jolting my cerebal cortex. Now, when the need comes up, I will KNOW it can be done and KNOW how to do it.
This type of article and content is the exact reason why I subscribe to sqlservercentral.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply