Will First Name + Last Name + Date Of Birth combination be unique enough? - sql

I need help with the algorithms/ database design for my current working on web-based application (I apologize for the long question in advance)
Application description:
I am building a customer check-in station (it's basically just a monitor that displays a webpage and was connected to a scanner) where customers who come into an office (similar to a library) can scan their office ID card (it has an unique bar code on it) to check-in, customer information (First name, Last name, date of birth, check-in time...) will be sent/saved onto server and the office administrator will be able to see who is in the office right now and do stuff...)
When creating ID card for a new customer, the only information needed is: first name, last name and date of birth (customer can be any ages from kids to elder) => system will generate a unique bar-code (16 digits) and print out a new ID card (with only the bar-code on it)
Problem:
If a customer forgot/ lost their ID card or sometimes the card is too old so the bar-code can't be scanned, customer can type in their first+last name and date of birth into the check-in station then system will search for (first name + last name + date of birth) and determine whether that customer existing and check them in. But it is possible that there is more than one person who has same name + birthday:
- system then can display all matched people to screen but how can customer know which one is them self?
- or that situation can be avoided if system would not allowing customer who has same name and dob to be saved the to database in first place. But then the customer who came "second" will be very upset that he/she can not have a card :))
Edit:
How do I deal with this problem, I mean this is just a office so we can not ask for SSN or driver license ... the check-in process have to be simple and quick some of them maybe a kids who don't have any ID or phone (they will come with their parents/guardians) and many of them are older people (older than 70, or even 80) they can't even type that why the "ID card - scanning idea is here to help them - all they need to do is scan their card... (I don't think they ever can remember the "security question"), SMS verify will not work (phone number may be changed, not all of customer have a phone, the carrier will be involved here (coverage, rate charge...) I don't want any of that ).
OK after read all your suggestion:
I am thinking about a 4 digit pass-code (like 3 digits security code in the back of a credit card) - it will be printed out in the ID card with the instructions and everything, this will be different from the unique customer number (used to scan), here how it works:
- when creating a new customer ID card, system will ask for an additional 4 digits pass-code and also print it out to the card, an algorithms also will be put there to make sure that customers who have same name + dob can't have same pass-code.
In case customer can't use/lost the card, after they entering name+dob to check-in, system only ask this 4-digit passcode if there are more than 1 matched person, otherwise if there is only 1 person matched, system will check-in them in right on.
if they ever forgot this pass code, I mean there is nothing else they can do for them self, the receptionist will have to somehow help them, what do you guys think, I am still open for suggestions?
My final solution:
Because the cards have nothing else (of customer information) rather than the bar code (customer number) on it so the best way is to preprint (pre-made)them, have them ready in the desk to give to new customers or for card replacement purposes.
When creating a new customer, receptionist will manually input first name + last name + dob + phone number (optional) + email (optional) + home address + customer number (as same as in the card that they about to give to the customer) +. submit, system will check for everything, if everything is good receptionist then give customer a new card => customer come back to check-in station and check-in.
When customers forgot card => they will need to see the receptionist => do verification process => receptionist will check them in manually.
When customer lost card or card is damaged => they will need to see the receptionist => do verification process => receptionist then give customer a replacement card => customer come back to check-in station and check-in.

Have each customer tell you two "security question" style data: Location of birth, favorite dish, ... These can serve as uniquifiers.
You can then prevent duplicates from being entered because in case there is a colliding registration the customer must simply chose a different question.

Some rambling thoughts:
You could assign users a PIN and use that to make the account unique. Presumably to insure that it is unique you would have to assign it, you can't let them invent one. (You could let them invent one and then verify it's unique. That might be good to allow people to use numbers that have some meaning to them so they can remember them.) The big catch to this is that if the person loses his PIN, you're stuck. If the PIN is printed on the card, then if the card is damaged or worn, yes, they could type in the PIN. But if they lost the card, they might have no other record of the PIN.
You could ask for their phone number and use that as an identifier. My grocery store does that for their discount card. I think almost everyone has a phone these days. For the small number who don't, you could generate a random number that looks like a phone number but is not valid (so it won't coincidentally duplicate any real phone number), and use it like a PIN. For example if you're in the US, you could make generated numbers all start 555-555 and then make the last 4 digits be like a PIN. Then the only people who would be a problem are those who don't have a phone AND who lost their card, which should be a very small number.
Is there any information in this system that is confidential, or are people committing to spending money? I mean, if someone walked up to a kiosk and typed in the name and birth-date of his next door neighbor and accessed that person's account, would that be a problem? You haven't said what the system does. If getting into the system gives someone access to the person's medical records or bank account or transcripts of his last confession to his priest, then you have to take steps to prevent unauthorized access, you can't let just anyone come up and claim to be someone else and get in. I'm reminded of a case a few years ago where a reporter got access to records of some politician's DVD rentals. He was apparently hoping to find that he had rented a lot of vile pornography or some such that he could use to embarrass the guy, though as it turned out it was mostly westerns. My point is that even seemingly innocent information could be embarrassing to someone under the right circumstances, so you have to be careful.
How often do people have lost or damaged cards? And are there clerks available who could help someone in such cases? That is, if 99% of the time someone comes in, swipes his card, and he's in and everything is good, and the number of times that someone has a lost or damaged card is very small, you could say that in those cases they have to go to a clerk and show the damaged card, or if they say they lost their card, show identification. Then the clerk can verify whatever and give them a new card. You could have the clerk search by name and have a screen that shows birth dates and addresses, ask the customer what their birth date and address is and if it matches one, give them a new card, if not, say I'm sorry you're not on file. This is quite different from a security point of view of showing the customer the list of birth dates and addresses and letting them pick one, as a customer could, (a) type in a common or overheard name and then pick any matching entry that shows up, or even (b) use this to find the address of someone they want to harass, and then you could be liable.

On the current project I met the same way to find a customer. The project is about TV stuff, so the second level of 'sieve' is address. And I think you need to expand the customer information: a username, an email, an avatar or something easy to remember (or send a SMS with code). Also you can add user friendly behavior: if a customer cannot decide which record about him/her, the customer should go through the wizard and add needed information. Yes, it's hard to find a general evidence for all customers, but you can support several kinds of extra information.
In other words: first name, last name, and birth date aren't enough for unambiguously getting a person.

Related

How should I design my RESTful API in this case?

I've got a DB with a lot of people of type (PLAYER, DOCTOR, TEACHER) where each person has an ID and location ID. There're some common fields like first name, last name but also some fields that are specific on person's occupation: number of injuries / the most serious injury type for PLAYER, number of patients for DOCTOR and can_teach_math for TEACHER.
I want to build an API to compute total compensation of all these people that accepts a list of IDs (optional), list of location IDs (optional). For example, if someone passes 3 personIDm API should return a response with an array where each row corresponds to a specific person. If someone passes locationIDs - API should return all people who are living in that area.
Originally, I was thinking I could just return people ID:
request = {..., person_id:[person-123, person-456], location_id = [location-1, location-2]}
response = {
[person_id:person-123, first_name=Alex, compensation=100],
[person_id:person-456, first_name=Alex2, compensation=102],
# anyone who lives in location-1, location-2
[person_id:person-13, first_name=Alex3, compensation=50],
[person_id:person-12, first_name=Alex4, compensation=52],
}
However UI engineer showed up and said they want to see
also some fields that are specific on person's occupation: number of injuries / the most serious injury type for PLAYER, number of patients for DOCTOR and can_teach_math for TEACHER.
in a response even though it makes API denormalized. That said, it makes sense to me since loading all the object info through GET persons/{ID} might take quite a long time. Without going too much of the details, let's see we don't care about speed -- is the proper way to design RESTful API is not to return
also some fields that are specific on person's occupation: number of injuries / the most serious injury type for PLAYER, number of patients for DOCTOR and can_teach_math for TEACHER.

Selenium IDE - verifyText in a multiple entries in a table (dynamically created ID's)

The system should make a entry in the database (lets say a car with a registration number).
The box in the table with the registration number has ex. ID232 . I have no problem with verifying the registration number of the first car that comes up in the results (The verification is done based on a search which brings results from the database). The problem comes if I want to verify the next car based on reg. number , because the second registration number box has the same ID.
An example:
Car ID Registration Number
1 BS2344 <--- ID232
2 BS3224 <--- ID232
The selenium IDE can verify the first entry, but the second verifyText will fail because it verifies the first one only (because the second box is has the same ID). The only difference is a automatically incrementing ID (Car ID) that I can use, but then i will have to input this manually (And the whole automation point is gone). The whole test process is to Create multiple Cars, and then verify them.
use the loop and verify the same Id as many times as the entries in the database. as the car code is generated randomly, for the same id different car code will be generated and you will be able to check for all the ids..
I hope you got my point..
hope this answer would help you!

Complex Names with Authorize.net AIM

How do the rest of you handle complex names when submitting a transaction to Authorize.net using AIM?
Nearly every ecommerce application on the planet asks the user to fill in the "Name as it appears on your credit card". For some odd reason, Authorize.net wants you to submit x_First_Name and x_Last_Name however.
This is fine when you're dealing with Mary Jones or Jack Smith. It becomes a real hassle when you've got Margret A. Jones-Robinson and H. William Robert Van Horn, Sr. though.
Is there a best practice here?
First & Middle names in the x_First_Name field?
Last Name, Hyphenated Name and/or Suffix in the x_Last_Name field?
Has anyone developed a routine to parse names accordingly?
Thanks!
Have two fields on your payment form. One for their first name and one for their last name. However the customer chooses to complete the form is how you should submit it (and save it in your database if you choose to do so). FYI, the name on the credit card is not used in the processing of the credit card so you do not have to transmit it to Authorize.Net to process the transaction. You should do it anyway as it helps to keep your records accurate and complete which is handy when doing audits of your transaction history.
You should generally try to avoid using one field for names as it opens up the possibility for people to enter bad information like, "The Smith Family" or "Barabara and Steve". By having two clearly delimited fields you greatly reduce the occurrence of this.
You should use 2 fields on your payment section. First name and last name.
The name on the credit card is actually used by certain cards for some services, so if you signed up for AVS and fraud detection they will use that name and provide feedback as to if its a match or not.
Alternatively, and what we have done in the past is ask the customer for:
-prefix
-first name
-middle initial
-last name
-suffix
This allows the customer to feel in control and you avoid them filling garbage in the 2 main fields (first name, last name). Authorize.net and other merchant service providers dont care for then other fields and you may choose not to either, it is just a way to keep the data "cleaner".

Recurring Orders

Hi everyone I'm working on a school project, and for my project I chose to create an ecommerce system that can process recurring orders. This is for my final project, I'll be graduating in May with an associates in computer science.
Keep in mind this is no where a final solution and it's basically a jumping off point for this database design.
A little background on the business processes.
- Customer will order a product, and will specify during checkout whether it is a one time order or a weekly/monthly order.
- Customer will specify a location in which to pick up their order (this location is specific only to the order)
- If the value of the order > 25.00 then it is accepted otherwise it is rejected.
- This will populate the orders_test and order_products_test tables respectively
Person on the back end will have a report generated for deliveries for the day based on these two tables.
They will be able to print it off and it will generate a list of what items go to what location.
Based on the following criteria.
date_of_next_scheduled_delivery = current date
remaining_deliveries > 0
Once they are satisfied with the delivery list they will press "Process Deliveries" button.
This will adjust the order_products_test table as follows
Subtract 1 from remaining_deliveries
Insert current date into date_of_last_delivery_processed
Based on delivery_frequency (i.e. once, weekly, monthly) it will change the date_of_next_scheduled_delivery
status values in the order_products_test table can either be active, hold, or canceled, expired
I just would like some opinions if I am approaching this correctly or if I should scratch this approach and start over again.
A few thoughts, though not necessarily complete (there's a lot to your question, but hopefully these points help):
I don't think you need to keep track of remaining deliveries. You only have 2 options - a one time order, or a recurring order. In both cases, there's no sense in calculating remaining deliveries. It's never leveraged.
In terms of tracking the next delivery date, you can just keep track of the day of the order. If it's recurring -- monthly or weekly, regardless -- everything is calculable from that first date. Most DB systems (MySQL, SQL Server, Oracle, etc) support more than enough date computation flexibility so that you can calculate this on the fly, as opposed to maintaining such a known schedule.
If the delivery location is only specific to the order, I see no use in creating a separate table for it -- it's functionally dependent on the order, you should keep it in the same table as the order. For most e-commerce systems, this is not the case because they tend to associate a list of delivery locations with accounts, which they prompt you about when you order more than once (e.g., Amazon).
Given the above, I bet you can just get away with 2 of your 4 tables above -- Account and Order. But again, if delivery locations are associated with Accounts, I would indeed break that out. (but your question above doesn't suggest that)
Do not name your tables with a "_test" suffix -- it's confusing.

Custom sort-order with SQL-Server and .NET Entity-Framework

I have a table I store contacts and their phones.
Contact: ContactId (int, PK), FirstName (varchar), LastName (varchar)
Phone: PhoneId (int, PK), ContactId(int FK), Number (varchar), SortOrder (tinyint)
I want that under each contact, the user should be able to maintain the priority of the phones, meaning that the SortOrder column of phone should be under each ContactId by consecutive numbers.
For exmple, when adding the first phone to a user, its SortOrder should become 1, for the second 2 and so on.
Say the user added 5 phone to a user, now he wants to move phone (with order) 3 to place 2, it should push current 2 to place 3 and vice versa.
If he want to make phone 1 to last it should 'pull' all the phones' SortOrder by -1, then assign previous 1 to 5.
I want this system to be consistent and not to have open edges where I have:
2 phones with identical sort-order values in one group
First phone in group with value higher than 1
Last phone in group with value higher or smaller than amount of phones in group
etc. etc. etc.
I think I am pretty clear so far (am I).
Now my question is, considering I retrieve the data with .NET EF in a desktop app, and I will be accessing the phones using the Contact.Phones navigation property.
Should implement this system in the DAL or in server AFTER INSERT, UPDATE trigger?
I personally think this has to be implemented on the server, cuz imagine different users play around with the same contact-phones at the same time, this might break the consistency, huh?
Any tips, links, code, advice jokes regarding this custom-sorting issue will be welcommed.
I also thought about ROWNUMBER() as a good idea of retrieving the data, but I need to maintain the sorting, not only selecting it.
Notes:
In general I asked the question in continuation of this answer, I decided to use, the contact-phone example was just to make things simple.
I've found this post discussing my issue but no technical advise was provided there.
Thanks in advance.
Your square pegging a round hole here.
Your answer CAN be as easy as Contact.Phones.OrderBy ( #p => #p.SortOrder ) then taking care of all of your phones in a Contact.SetPhone( phone, order ) method which can encompass whatever custom logic you wish.
Also since this is business and view logic your persistence store shouldn't be aware of whats going on.