I am building a UK wide competition website that limits entries in a given household/address to 1 per week, and 4 overall.
I need to know the best practice as to what fields to check when seeing if they pass the entry requirement.
I can use house number and postcode, but what is stopping the user saying "Flat xx" , or "Room xx" to get more entries? Using email address would be ineffective, as they can just register a new Gmail address if they want.
They would also "miss-spell" their surname were I to use that as part of the check. Also, who is to say that two people living in the same house won't have the same surname?
Another way I suppose is to use a phone number as a unique identifier. But, people may use all the households phones to increase their entry count?
Is there a tried and tested method that will stop most cases of people entering more that they should?
You could insert their ip address in the validation process, combined with some tricky flash cookies. But that can be avoided also.
So, there is no tested and tried method for this sort of things - Google/Yahoo/M$ all have big problems because of spammers.
You could ask your users to send an SMS number with a tax on it and they receive a PIN number which they can use. Now, the tax you put on that number has to be small enough to not scary them, but big enough to discourage them from sending multiple SMS
Related
I'm a little stumped on whether i can make this process of changing addresses easier. I'll explain the situation:
Basically I have three entities, Students, Addresses, StudentsAddresses. Students have many addresses, since they can change alot and rapidly (especially foster kids / homeless kids). So ill be changing them a lot. However based on each address I Want a user to attach (enter it via the UI) the price it would cost to pick that student up via bus service. So my initial thought was, ok, let me attach a column onto my join table 'StudentsAddresses' called 'dailyPrice', this is the cost for each day a student is picked up, and another column called 'adjustmentPrice', which is an additional cost for whatever special circumstance that requires extra work to pick up a student. Is my thinking going to cause me problems the more students I have in the future? Will it get harder to manage?
Another option I thought about, was creating a new Table called Pricing. And another join-type table called StudentsAddressesPricing
StudentsAddressPricing has three columns,
studentId
addressId
pricingId
each field connects the three together. So if i ever needed Students, with their addresses, and the pricing, i would query this table and eager load Students, Addresses, and Pricing. Does this approach seem much cleaner since i've abstracted pricing out a bit? Trying to determine the best way to go about this without having to many headaches in the future incase I wan't to add more attributes pricing related, or address related.
And then I even thought, hey what if pricing is just different for one day? How would I even consider that. Would I need a different kind of entity to handle that? Is doing alot of joins going to hurt my application performance?
Just looking for some insight on how others would do it, and criticism on why im off the ball.
The main question you should ask yourself is: on what does the price depend?
If the price is determined by the address, you might as well add it to addresses. If the price also depends on the student (e.g., depending on their financial situation), it would make sense to put it into studentsaddresses.
In other words: The table where the price is stored should have foreign keys to everything outside the table that determines the price. If that makes it fit into one of the existing tables, keep it there.
I have an application in which I register a user using only their email and password. Then later on, they fill in their profile, which includes their personal information such as numbers, address, the hours they work during the week, etc.
I'm confused now whether to store all that data in the same table or to have the following:
users (for authentication), persons (for the profile), address (for um, addresses), numbers (you get the gist).
I would like to know a DBA's input on this. How would you design this database for a userbase of 500 people, give or take. Are there going to be problems in the long run if I keep all the fields - around 30 right now - in the same table?
It is a good idea to separate site-used data from invoicing data.
When you are displaying a homepage after your user logs in, you usually want to display username and avatar. Also, you use email and other account info to log in. That is probably some stuff you want to keep handy all the time. Move it into one table then.
Addresses (invoice, delivery, etc.) and phone numbers are usually stored separately, as you only need those when placing an order.
Rule of thumb: keep column count under 30, read as few tables as possible. Of course you should design properly (never mix entities, etc.), but this rule is a simple check that you are not creating something awful.
I have a conceptual question.
My DB has a table that stores information about people. One of it's fields is their phone number (8-digit for my country).
The thing is that in some cases, two or more people will have the same phone number.
My question is: will it be a better choise to store the phone numbers on another table and then reference it by a foreign key instead of just storing them as a field?If so, will the result be the same for whatever the size of the DB is?
I don't know if this will make any difference, but the table will have no more than 600.000 - 800.000 records, and I guess the coincident phone numbers will be about 10% of the total records.
EDIT:
-Each record can have up to 4 phone numbers (two lines and two cells)
-Both cases will occur, there will be sometimes where the users will be looking for all the people having a specific number, and times where the user will want to know what are all the phone numbers a person has
Technically to be normalized, you would have a separate Phone number table and then a PersonPhonenumber table.
However, in practice I have rarely seen this structure for phone numbers and addresses. For one, it is easy to make a mistake and update more than one person's addess or phone when you only mean to change one. For another it adds an extra join that seems unnneeded to most people. You aren't really gaining much by going to this level other than a small amount of duplication.
The real decider is how you are going to use and update the numbers. If you want to update all the people with the same number frequently, it is better to go fully normalized. If you will usually only want to update one person at a time, it is probably less risky to only have a Person table and a PersonPhone Number table.
If you want history, then I would go with a person table and aPersonPhoneNumber history table. It would have the personid, the phone number, the startdate and the end date. So when John and Mary get divorced, his phonenumber woudl have an end date but hers woudl not and you could clearly see who had the number when.
If you have more then 1 phone number per person
There is a good reason to set new table like:
id, user_id, phone, type, description
So type could be list of
Home, Work, Office2, Boss, Wife, Fax, Mobile etc...
and description like
"work hours only", "evening", "24x7", "Emergency only" etc
If you really manage phone book for your application that is good idea to separate phone numbers from original user table.
If you have two people with the same phone number you will encounter a problem when searching for a specific phone number. A search for a specific phone number will sometimes return more than one result (10% according to your estimate). If you search by phone number AND by people, you can require all searches for a phone number to include a user identifier (first name, last name, location, etc). It depends on what your objective is.
Usually the phone number is just a number, and without a person has no meaning.
So you store it in the Person table.
But it you work for a telephone company for which a phone number has a different meaning and usage (like history, phone lookup, billing) then it should be stored in a separate table. I hope it helped.
I am trying to implement a customers list in an application that I derive the DB from MySQL,
Currently we would take the first and last name, dob, and phone number of said people.
To search for the customer we may enter a phone number and ideally it will find the person with the correct phone number - but I want to enter a fail-safe - lets say the previous representative entered the phone number slightly incorrect lets say the phone number is 7777777777 and the person accidentally types 7777077777 I would still want it to show up in query of course in order of relevance - so 7777777777 would be the preferred and top result.
Select * from Customers WHERE Pnumb Like....
would be what I would expect however I would not know how to implement that.
Any help is greatly appreciated as I can not find much (any) information on this online.
I'm planning a database who has a couple of tables who contain plenty of address information, city, zip code, email address, phone #, fax #, and so on (about 11 columns worth of it), a table is an organizations table containing (up to) 2 addresses (legal contacts and contacts they should actually be used), plus every user has the same information tied to him.
We are going to have to run some geolocation stuff on those addresses too (like every address that's within X Kilometers from another address).
I have a bunch of options, each with its own problem:
I could put all the information inside every table but that would make for tables with a very large amount of columns which I'd have problems indexing, and if I change my address format it'll take a while to fix it.
I could put all the information inside an array and serialize it, then store the serialized information in one field, same problem with the previous method with a little less columns and much less availability through mysql queries
I could create a separate table with address information and link it to the other tables either by
putting an address_id column in the users and organizations table
putting a related_id and related_table columns in the addresses table
That should keep stuff tidier, but it might create some unforeseen problems with excessive joining or whatever.
Personally I think that solution 3.2 is the best, but I'm not too confident about it, so I'm asking for opinions.
Option 2 is definitely out as it would put the filtering logic into your codes instead of letting the DBMS handle them.
Option 1 or 3 will depend on your need.
if you need fast access to all the data, and you usually access both addresses along with the organization information, then you might consider option 1. But this will make it difficult to query out (i.e. slow) if the table get too big in mysql.
option 3 is good provided you index the tables correctly.