ALTER proc [Voting].[NotifyVotersOfBallot] @ScheduleID uniqueidentifier

as

declare @Rows int
declare @Template varchar(max)

set nocount on
set xact_abort on

–make sure we don’t send twice
if not exists (select * from Voting.NotificationSchedule where ScheduleID = @ScheduleID and DateSent is null)
    begin
        raiserror (‘This schedule item has already been processed. Add a new schedule if you want to send again’, 16, 1)
        return
    end

–get the template once
select
    @Template = TemplateHTML
from Voting.Templates
where
    TemplateName = ‘BallotEmail’

begin transaction

insert into Voting.Email (
    MsgFrom,
    MsgTo,
    Subject,
    Message,
    Priority,
    DBName)
select
    ‘hq@sqlpass.org’,
    EV.EmailAddress,
    ‘PASS Vote: ‘ + B.Title,
    Voting.MergeBallotInfo (@Template, B.BallotID, EV.VoterID, B.Title, B.Description, B.ClosingDate),
    2,
    db_name()
from Voting.EligibleVoters EV inner join Voting.Ballot B on EV.BallotID = B.BallotID
inner join Voting.NotificationSchedule NS on B.BallotID = NS.BallotID
where
    EV.HasVoted = 0
    and B.ClosingDate > GetUTCDate()
    and NS.ScheduleID = @ScheduleID
set @Rows = @@Rowcount

–mark as done
update Voting.NotificationSchedule set
    DateSent = getutcdate(),
    NumberSent = @Rows
where
    ScheduleId = @ScheduleID

commit transaction

I wanted to make this as set and forget as possible, and it’s not as easy as saying each ballot gets 2 reminders. I created this table which can be populated with as many rows as needed, but I’d guess the average will be 2-3. I logged the number of emails sent which may be overkill, but it’s a nice way to know that things happened as expected.

I didn’t avoid loops entirely. I could have written the above to handle all notifications that were due at once (rarely more than one), but I hate not having the ability to just send one if I need to – say a quick resend if something has failed. I’m using a read only cursor, and it’s really a just in case solution, doesn’t cost much to code or execute in this context.

ALTER proc [Voting].[VotingProcessSchedule]

as

declare @ScheduleId uniqueidentifier

set nocount on

DECLARE curSchedule CURSOR
READ_ONLY
FOR SELECT scheduleid from Voting.NotificationSchedule
where
    Datesent is null
    and DateToSend > GetUTCDate()

OPEN curSchedule

FETCH NEXT FROM curSchedule INTO @ScheduleId
WHILE (@@fetch_status <> -1)
BEGIN
    IF (@@fetch_status <> -2)
    BEGIN
        exec Voting.NotifyVotersOfBallot @ScheduleID

    END
    FETCH NEXT FROM curSchedule INTO @ScheduleId
END

CLOSE curSchedule
DEALLOCATE curSchedule

Finally, we’ll have to do some reporting, which for now consists of selecting from the view, but not a big thing to add a simple RS report to finish things up:

CREATE view [Voting].[BallotResults]

as

select
    b.BallotID,
    b.Title,
    bd.Title as BallotOption,
    isnull(a.VotesCast,0) as VotesCast
from Voting.Ballot B inner join Voting.BallotDetail BD
on B.BallotID = BD.BallotID
left join
(
select
    BallotDetailID,
    count(*) as VotesCast
from Voting.VotesCast
group by
    BallotDetailID)
a on BD.BallotDetailID = A.BallotDetailID

For security there is a role called Voter, and I’ve granted execute on the procs that can be called from the web app. Not much else to it. Next post will look at some of the UI pieces.

We start with the main proc we call every time someone hits the voting page. We may or may not get ballotID and VoterID, and you can see I’m doing something you probably don’t see often, returning both output parameters and a resultset.

ALTER proc [Voting].[GetBallotDetails]
    @BallotID uniqueidentifier,
    @VoterID uniqueidentifier,
    @IsEligibleToVote bit output,
    @HasVoted bit output

as

set nocount on
set xact_abort on

select @IsEligibleToVote = voting.IsEligibleToVote(@BallotID, @VoterID)
select @HasVoted = voting.HasVoted(@BallotID, @VoterID)

select
    B.BallotID,
    B.Title as ItemTitle,
    B.MaxSelection,
    B.MinSelection,
    B.Description,
    B.ClosingDate,
    BD.BallotDetailID,
    BD.Title as DetailTitle
from voting.BallotDetail BD Inner join voting.Ballot B on B.BallotID = BD.BallotID
where
    B.BallotID = @BallotID
    and B.ClosingDate > getutcdate()

You’ll notice I’m calling two functions. I thought I’d be able to reuse them and it made it easy to follow:

ALTER FUNCTION [Voting].[HasVoted]
(
    @BallotID uniqueidentifier,
    @VoterID uniqueidentifier
)
RETURNS bit
AS
BEGIN
    — Declare the return variable here
    DECLARE @Result bit

    if exists (select * from Voting.EligibleVoters where BallotID = @BallotID and VoterID = @VoterID and HasVoted = 1)
        set @Result = 1
    else
        set @Result  = 0

    — Return the result of the function
    RETURN @Result

END

ALTER FUNCTION [Voting].[IsEligibleToVote]
(
    @BallotID uniqueidentifier,
    @VoterID uniqueidentifier
)
RETURNS bit
AS
BEGIN
    — Declare the return variable here
    DECLARE @Result bit

    if exists (select * from Voting.EligibleVoters where BallotID = @BallotID and VoterID = @VoterID)
        set @Result = 1
    else
        set @Result  = 0

    — Return the result of the function
    RETURN @Result

END

It worked out ok. It was one of those cases where in hindsight I wonder if programming by exception (throwing an error if anything didn’t match) might have been cleaner on the app side, but it’s not a technique I normally use and am biased against.

Casting a vote is a big deal of course, and hopefully I got this right. Here I don’t just rely on what I “know” in the UI, I want to make sure I enforce the voting rules. You can see I did reuse my functions. I cheated here a little by only allowing voters to vote once, that means I don’t have to check for scenarios such as picking one option and submitting, then picking a second option and submitting. Restricting to one call means I can just check all the conditions then, with little complexity.

USE [Vote]
GO
/****** Object:  StoredProcedure [Voting].[CastVote]    Script Date: 06/11/2010 09:33:59 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER proc [Voting].[CastVote]
    @Details varchar(8000),
    @BallotID uniqueidentifier,
    @VoterID uniqueidentifier
as

declare @MaxVotes int
declare @MinVotes int
declare @ActualCount int
declare @Temp table (DetailID uniqueidentifier)

set xact_abort on
set nocount on

–check that they are eligible to vote
if Voting.IsEligibleToVote(@BallotID, @VoterID) = 0
    begin
        raiserror (‘You are not an eligible voter for this ballot.’, 16, 1)
        return
    end

–see if user has already voted on this ballot
if Voting.HasVoted(@BallotID, @VoterID) = 1
    begin
        raiserror (‘You have already voted on this ballot.’, 16, 1)
        return
    end

–get the max number of selections allowed for this ballot
select
    @MaxVotes = MaxSelection,
    @MinVotes = MinSelection
from Ballot B
where
    BallotID = @BallotID

–convert list of votes to a table
insert into @Temp (DetailID) select convert(uniqueidentifier, Param) from voting.SplitCommaDelimitedString (@Details)

–get count of votes
select @ActualCount = count(*) from @Temp

–make sure no nulls
if @ActualCount is null
    set @ActualCount = 0

–check that #votes don’t exceed max
if @ActualCount > @MaxVotes
    begin
        raiserror (‘Selected more choices than are allowed on this ballot.’, 16, 1)
        return
    end

–and min
if @ActualCount < @MinVotes
    begin
        raiserror (‘Selected fewer than the required number of choices on this ballot.’, 16, 1)
        return
    end

begin transaction

–record the vote  �
insert into voting.VotesCast (
    BallotDetailID,
    VoterID)
select
    DetailID,
    @VoterID
from @Temp

–mark as voted
update voting.EligibleVoters set
    HasVoted = 1
where
    BallotID = @BallotID
    and VoterID = @VoterID
commit transaction

To provide a voting link to a voter, we need to build an email message, which here we do by inserting a row into the Voting.Email synonym, which points to a different db and a process that converts the row into the final SMTP message. The work of populating the template is done by a function also shown below:

ALTER proc [Voting].[SendVoterLink] @BallotID uniqueidentifier, @EmailAddress varchar(150)

as

declare @Template varchar(max)
declare @VoterId uniqueidentifier

set nocount on
set xact_abort on

–log the request
insert into Voting.VoterInquiries (
    BallotID,
    EmailAddress)
values (
    @BallotID,
    @EmailAddress)

–see if possible
if not exists (select VoterID from voting.EligibleVoters where EmailAddress = @Emailaddress and ballotID = @ballotID)
    begin
        raiserror (‘You are not listed as an eligible voter for this ballot using the provided email address’, 16, 1)
        return
    end    

–get the template once
select
    @Template = TemplateHTML
from Voting.Templates
where
    TemplateName = ‘BallotEmail’

insert into Voting.Email (
    MsgFrom,
    MsgTo,
    Subject,
    Message,
    Priority,
    DBName)
select
    ‘hq@sqlpass.org’,
    EV.EmailAddress,
    ‘PASS Vote: ‘ + B.Title,
    Voting.MergeBallotInfo (@Template, @BallotID, EV.VoterID, B.Title, B.Description, B.ClosingDate),
    2,
    db_name()
from Voting.EligibleVoters EV inner join Voting.Ballot B on EV.BallotID = B.BallotID
where
    EV.HasVoted = 0
    and EV.BallotID = @BallotID
    and B.ClosingDate > GetUTCDate()
    and Ev.EmailAddress = @EmailAddress

USE [Vote]
GO
/****** Object:  UserDefinedFunction [Voting].[MergeBallotInfo]    Script Date: 06/11/2010 09:37:58 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER FUNCTION [Voting].[MergeBallotInfo]
(
    @Template varchar(max),
    @ballotID uniqueidentifier,
    @voterid uniqueidentifier,
    @Title varchar(50),
    @Description varchar(4000),
    @ClosingDate datetime
)
RETURNS varchar(max)
AS
BEGIN

    declare @Temp varchar(max)

    set @Temp = Replace(@Template, ‘{BALLOTID}’, @BallotID)
    set @Temp = Replace(@Temp, ‘{VOTERID}’, @VoterID)
    set @Temp = Replace(@Temp, ‘{TITLE}’, @Title)
    set @Temp = Replace(@Temp, ‘{DESCRIPTION}’, @Description)
    set @Temp = Replace(@Temp, ‘{CLOSINGDATE}’, @ClosingDate)

    RETURN @Temp

END

Tomorrow we’ll cover sending out the notifications to the entire eligible voter list and the view used for reporting.

Here are the tables I ended up with:

As you might guess Ballot holds the overall description of what is being voted on, BallotDetail holds the options that voters can pick from. Here’s the DDL for those two:

CREATE TABLE [Voting].[Ballot](
    [BallotID] [uniqueidentifier] NOT NULL,
    [DateAdded] [datetime] NOT NULL,
    [Title] [varchar](50) NOT NULL,
    [Description] [varchar](4000) NOT NULL,
    [OpeningDate] [datetime] NULL,
    [ClosingDate] [datetime] NOT NULL,
    [MinSelection] [tinyint] NOT NULL,
    [MaxSelection] [tinyint] NOT NULL,
CONSTRAINT [PK_Election] PRIMARY KEY CLUSTERED
(
    [BallotID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [Voting].[BallotDetail](
    [BallotDetailID] [uniqueidentifier] NOT NULL,
    [DateAdded] [datetime] NOT NULL,
    [Title] [varchar](75) NOT NULL,
    [BallotID] [uniqueidentifier] NOT NULL,
CONSTRAINT [PK_BallotDetail] PRIMARY KEY CLUSTERED
(
    [BallotDetailID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [Voting].[BallotDetail]  WITH CHECK ADD  CONSTRAINT [FK_BallotDetail_Ballot] FOREIGN KEY([BallotID])
REFERENCES [Voting].[Ballot] ([BallotID])
GO

ALTER TABLE [Voting].[BallotDetail] CHECK CONSTRAINT [FK_BallotDetail_Ballot]
GO

ALTER TABLE [Voting].[BallotDetail] ADD  CONSTRAINT [DF_BallotDetail_BallotDetailID]  DEFAULT (newid()) FOR [BallotDetailID]
GO

ALTER TABLE [Voting].[BallotDetail] ADD  CONSTRAINT [DF_BallotDetail_DateAdded]  DEFAULT (getutcdate()) FOR [DateAdded]
GO

HQ would load those two tables first, then load the list of eligible voters into Voting.EligibleVoters where they get assigned a “voterid” in the form of a uniqueidentifier. Eventually we will send a email to each eligible voter where the url looks something like “pass.org/vote.aspx?ballotid=X&voterid=Y. You’ll notice I cheated some, adding a HasVoted flag here rather than just determining it based on whether they have actually cast a vote:

From there votes get inserted into VotesCast:

For the remaining tables, VoterInquiries is used to log when voters arrive at the site only knowing a ballotid, giving us the ability to help out by providing a generic link like “pass.org/vote.aspx?ballotid=x” and then they can enter their email address – if it matches we send them a full voting link.

VotingTemplates has only one row for now, the HTML template we send to voters. It contains tokens that we fill in to show the ballot name, URL, etc. Finally, the NotificationSchedule table allows us to set up a series of emails to remind voters for each ballot to vote.

I can’t say I agonized over the design. I used uniqueidentifiers because I planned to pass them around in the URL querystring (which ruled out using newsequentialid()) and I used a schema other than dbo (Voting) so that if we like the solution we can just add it to the main PASS db rather than having a separate Voting db. I tried to set reasonable primary keys and foreign keys, but haven’t done any load testing (that time thing again!). While I might be missing an index or two, given the low volume of data and low number of concurrent users, I’m not expecting any tough performance issues.

I’ve uploaded scripts for all the tables here. In the next post we’ll look at the data access pieces on the server.

Ten years later those core tables are still there, still working.

Good design is worth doing, but a lot of times what we call ‘bad design’ doesn’t matter as much as we think it does. I’d take a good normalized design with ugly primary keys over a highly denormalized design with integer keys any day.

On any given day we do the best we can. Sometimes that means fixing or work around problems created by those with less knowledge or different styles than we have. I try to neither complain nor gloat in such cases, they made something work, now they are asking me to make it work better – that’s what I do!

But being a data guy, it was the airlines solution to tracking this that caught my attention. How would you design your database to handle the situation where someone buys two tickets for one person? It’s important to know the number of ‘souls on board’ in case of a crash at the very least. How did the big guys do it?

• Southwest – makes the 2nd seat in the same name, but the middle name is “XS”, for extra seat
• Continental – changes the first name on the 2nd seat to “Extra Seat”
• American – just blocks the seat from being sold

It kinda feels like maybe they don’t like selling the extra seat because it’s hard to keep track of!

It’s one of those data modeling riddles that doesn’t have a perfect answer. I think I’d lean toward a ‘ExtraSeat’ column on the seat assignment record that pointed to the master/parent seat. Easy to identify which seats are vacant in flight, and now we avoid the weirdness of the person or two that enters their name as Extra Seat!

I might do it differently than they would, but their works, and it’s an edge case, so good enough is good enough!