Smile And Dial CRM – Part 1 – The problem with direct change

Welcome back to SmileAndDial CRM’s journey to remove phone numbers as a fundamental constraint.  In the introduction I introduced SmileAndDial CRM, a loathsome service for boiler rooms, pump and dumps, extended car warranties, and other horrid outbound call centers needs.  SmileAndDial has a problem, all contacts need a phone number and they need to transition away from phone numbers to enable their customers to send spam.How fundamental are phone numbers?  Let’s begin with the data model and how it reinforces the constraint.

Phone Numbers As Primary Keys

As the data model leaves no doubt, to SmileAndDial, you are nothing but a number.
Phone number is the primary key used throughout the system.  The developers made an interesting trade off – in exchange for a bigint primary key, which doesn’t have great indexing, they got a system with no joins.

No Joins?

That’s right!  Because the phone number is the primary key, users can enter a phone number into any search field and the system can use it directly without having to join against the Contact table.


When was the last time I called a contact?
“Select max(Date) from Calls where phone = [phone]”

How much have we sold to a contact?
“Select sum(price) from Sales where phone = [phone]”

Few operations need to join back to the Contact table, which reduces code complexity.

What Happens If There’s No Phone?

Now we get to the crux of the constraint – nothing works without a phone number.


Simply updating the Contact creation logic to allow phoneless contacts won’t work.  The new contact can’t have notes or sales without a phone number.


In part 2, we will start TheeSeeShipping our way out of this mess.  By delivering incremental, iterative changes that we will reduce risk and increase customer value.

3 comments On Smile And Dial CRM – Part 1 – The problem with direct change

Leave a Reply

Site Footer

%d bloggers like this: