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.
Related
I am developing a php/mysql system for a legal advice agency. Clients are recorded in a table ‘clients’ which contains (amongst others) the columns clientid and postcode. (Note this is in the UK)
A client then registers for advice and a matter is opened. The matters table contains columns mattered, client and legalid.
Legalid refers to a table ‘legal’ which has columns legalid and legal (legal is the type of legal advice e.g. employment, housing etc)
What I need to be able to do is to count the number of people receiving advice in particular areas grouped by the first part of the UK postcode. I think I can do this except I don’t know how to do the postcode grouping as the first part could be 2, 3 or 4 characters. For example, the postcodes might be E2 6TY or E14 7YU - I want to group by E2 and E14 etc. Also, in some cases a client doesn't want to provide the whole postcode so only the 1st part is entered.
Has anybody any guidance as to how I might be able to do this grouping?
Many thanks
You can do
group by SUBSTRING_INDEX(postal_code, ' ', 1)
There are lots of posts on stackoverflow where people use and give examples of substring_index so just do a search for it.
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.
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.
I'm working on a web application where I need to do some research before I implement the database. I hope you can help me make some good decisions before I start to code.
Today i have a database that among other things contains about two million contacts in a table
Contact:
cid, name, phone, address, etc...
Users of the application can search the contact table based on different criteria, and get a list of contacts.
Users are stored i a separate database table
User: uid, name, email, etc...
Now I want to make the users able to store a search result as a selection. The selection has to be a list of cid's representing every contact in the search result the user got. When the selection is stored, a user can open the selection and add notes, statuses etc to the different contacts in the selection.
My first thought is to make a selection table and a selection-contact mapping table like this:
Selection: sid, name, description, uid, etc
SelectionContactMap: sid, cid, status, note, etc...
With an average selection size between 1 000 and 100 000 contacts, and several thousand users storing many selections, I see that the SelectionContactMap table is going to grow very big very fast.
The database is MySql and the application is written in PHP. I'm on a limited budget so I can not throw unlimited hardware on the task.
I'm I on the wrong way here?
Do you have any suggestions to solve this the best possible way?
Other database?
MySql specific suggestions, table type etc?
Other database design?
Any comments and suggestions are appreciated.
Thanks in advance :)
-- Tor Inge
Question: What happens if the results of the query change - eg: a selected contact no longer has the chosen attribute or a new contact gets added?
If the answer is "The result set should be updated" - then you want to store the criteria in the database, not the results themselves.
If you need to cache the results for a period of time, this may be better handled by the application, not the database.
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