(revised) I have a web app where information will be entered for a user. First and last name as well as 3 Affiliations (primary, secondary, and tertiary) associated with the person. Each affiliation has 3 components (title, department, and university). So for example one record could be for:
User: Bob, Robertson
Affiliation1: Professor, Chemistry, U. Florida
Affiliation2: Director, Amazing Chemistry Institute, U. Florida
Affiliation3: Affiliated Faculty, BioChemistry, Florida Tech.
Also, Title and Department are text input fields but Univ. refers to a specific list of about 3000 university names 'univ_name' which is why it has it's own table. also affiliationOrdinal would be something like (1st, 2nd, 3rd)
Users Affiliation Univ.
======= ============ =========
id_user id_affiliation id_univ
FirstName id_user univ_name
LastName affiliationOrdinal
title
department
id_univ
Thanks Sean for your feedback, I started thinking of this more as a user with multiple addresess type of problem and that has been solved many times over it seems. I picked this one as a reference. Mysql database design for customer multiple addresses and default address. So the above should be a bit closer to workable right?
Related
My Goal: To find out which University has the larger amount of user (DISTINCT and COUNT in MySQLi).
I've been developing a survey website for Portugal, England and France.
In the survey some questions answer has predefined answer options.
For example: Gender, Living Country, Graduation Level (undergraduate, graduate, PhD, BBA etc)
But I also have questions where users need to write down the answers.
For example, University Name (where the user studied).
Two users filled the form as follow:
In this case the text "University of Glasgow" in English and the text "Universidade of Glasgow" in Portuguese is difference but it's the same institute.
So, these two institute has one user but the truth is this (as both are originally same University) University has two users.
My Question: How can I get the expected result?
I was planning to use Google translate but I it won't be accurate.
I also thought about to have all the University name in 3 languages but there are more than thousands of University, so it may not be efficient.
The structre I thought for table is,
survey_table
id, que_en, que_fr, que_pt, university_name
statistics_table
id, university_name, count
You could use localization for the university name. Check the docs here:
https://laravel.com/docs/5.7/localization
Make your users choose from a drop down list based on their locale (language)
So I've been developing a sort of data entry platform within accessing using forms and subforms.
I have a form titled PHYSICIAN. Each physician will have basic data like first/last name, DOB, title, contract dates, etc. The aspect I'm wanting to cover is addresses as they may have multiple, since they may work/practice at 2 or 3 or even 10 different locations.
Instead of having our data entry team key in a full record each time they need to add an address, I'd like a way for the form to retain ALL information not related to the address.
So if Ken Bone works at 7 places, I want to allow them to key all of those addresses a bit more efficiently than creating a new record.
There's one main issue I'm running into --- A subform or autopopulate option doesn't necessarily increment the autonumber ID (primary key) for the record. All of the information is being stored in 1 master table.
Is there a way around this or a more logical approach that you folks might suggest?
I recommend that you have a couple of tables perhaps even three.
tblDoctorInfo
- Dr_ID
- Name
- DOB
- Title
tblAddresses
- AddressID
- Address1
- Address2
- City
- State
- Zip
- Country
tblDr_Sites
- DrSites_ID
- Dr_ID
- AddressID
The tables might have data like this.
tblDoctorInfo
1, Bob Smith, 12/3/1989, Owner
2, Carl Jones, 1/2/1977, CEO
3, Carla Smith, 5/3/1980, ER Surgeon
tblAddresses
1, 123 Elm St, Fridley, MN 55038
2, 234 7th St, Brookdale, MN 55412
3, 345 Parl Ave, Clinton, MN 55132
tblDr_Sites
Then you could associate the tables with the third table. (Note each of the three tables have an ID field that increments).
1,1,1 This record means Dr. Bob works in Fridley
2,1,2 This record means Dr. Bob works in Brookdale
3,3,1 This record means Dr. Carla works in Fridley
4,2,3 This record means Dr. Carl works in Clinton
5,2,2 This record means Dr. Carl works in Brookdale
6,2,1 This record means Dr. Carl works in Fridley
I am implementing a voting feature to allow users to vote for their favourite images. They are able to vote for only 3 images. Nothing more or less. Therefore, I am using checkboxes to do validation for it. I need to store these votes in my database.
Here is what i have so far :
|voteID | name| emailAddress| ICNo |imageID
(where imageID is a foreign key to the Images table)
I'm still learning about database systems and I feel like this isn't a good database design considering some of the fields like email address and IC Number have to be repeated.
For example,
|voteID | name| emailAddress | ICNo | imageID
1 BG email#example.com G822A28A 10
2 BG email#example.com G822A28A 11
3 BG email#example.com G822A28A 12
4 MO email2#example.com G111283Z 10
You have three "things" in your system - images, people, and votes.
An image can have multiple votes (from different people), and a person can have multiple votes (for different images).
One way to represent this in a diagram is as follows:
So you store information about a person in one place (the Person table), about Images in one place (the Images table), and Votes in one place. The "chicken feet" relationships between them show that one person can have many votes, and one image can have many votes. ("Many" meaning "more than one").
I don't know how to design my mysql webdatabase for a shop.
The scenario is for a site selling guided tours.
Each tour can be either a Private, a Semi-Private or a Group Tour. The price per person changes per tour type. BUT ALSO for the Private tours, the price per person varies depending on the number of persons. However it varies by different amounts depending on tour. How would i create a 'Tour/Product' record?
e.g. Let's say:
Tour of Vatican (tour has various bits of data - name, description, meeting point, duration, etc). Semi-Private tour costs 50 euro per person. Group tour costs 45 euro per person. Private tour costs (140 euro for 1-2 people), or 180 euro for 3 people, or 200 euros for 4 people, or 225 euros for 5 people or 240 euro for 6 people or for 7 people or more it costs 43 euro per person.
HOWEVER for the Tour of Coliseum (tour has same bits of data - name, description, meeting point, duration, etc), Semi Private costs 40 per person. Group costs 25 per person. Private tour costs (100 euro for 1-2 people), or 135 euro for 3 people, or 160 euros for 4 people, or 175 euros for 5 people or 180 euro for 6 people or for 7 people or more it costs 25 euro per person.
How would i structure the data in the database - 2 tables? 3 tables?
Totally confused....
Thanks
Tom
From what I understand from your post, the price alters depending on three different things:
The tour: the price for the Tour of Vatican is not similar with the price for the Tour of Colloseum.
The type of the tour: Private, a Semi-Private or a Group Tour.
The number of persons on the tour.
Since there is no exact (constant) price per person on any of the given options, I would go for a three tables approach.
The digaram is detailed in the below picture and works under the following assumptions:
There are three tables: Tour (containing the description for each individual tour); TourPriceOptions (containing the individual price options records) and TourType (which at all times, will contain just three records: Private, Semi-Private and Group Tour);
There are just two assumptions that you have to do:
A tour can have multiple price options (1 to many relationship)
An price option can have just one single tour type (1 to 1 relationship)
How to code this up:
Whenever the administrator of the store creates another tour in the backend of the store, he should be able to add multiple price options. In order to do this you will need to:
Create a new tour: a function which inserts in to the database a new entry in the tour table.
Get the id of the recently created tour: if there is only one person adding information at any given time, then there is a good bet to write a function that returns the id of the latest added tour.
Add pricing options based on the id_tour: insert a new price option based on the id_tour variable. Remember to assign a tour_type from one of the already predefined categories.
Whenever you want to return these values, just write a query that allows you to retrieve information based on the tour the user is currently browsing.
Additional things to research: Dynamic Forms - They will help you when you don't know how many price options an admin might want to add for a specific tour
Address records are probably used in most database, but I've seen a number of slightly different sets of fields used to store them. The number of fields seems to vary from 3-7, and sometimes all fields are simple labelled address1..addressN, other times given specific meaning (town, city, etc).
This is UK specific, though I'm open to comments about the rest of the world too. Here you need the first line of the address (actually just the number) and the post code to identify the address - everything else is mostly an added bonus.
I'm currently favouring:
Address 1
Address 2
Address 3
Town
County
Post Code
We could add Country if we ever needed it (unlikely).
What do you think? Is this too little, too much?
The Post Office suggests (http://www.postoffice.co.uk/portal/po/content1?catId=19100182&mediaId=19100267) 7 lines:
Addressees Name
Company/Organisation
Building Name
Number of building and name of thoroughfare
Locality Name
Post Town
Post Code
They then say you do not need to include a County name provided the Post Town and Postcode are used.
The BSI have BS 7666 - that covers all addressing. I recommend you look there.
The 2000 version recommends
An address shall be based upon a logical data model comprising the following entities:
addressable object, with sub-types:
primary addressable object;
secondary addressable object;
street;
locality;
town;
administrative area, a.k.a. district;
county;
postcode.
See: http://landregistry.data.gov.uk/def/common/BS7666Address
I don't know whether this is minimal (I doubt it) but the heading on my cheque book says something pretty close to:
Lloyds TSB
Isle of Man Offshore Centre
Peveril Buildings
Peveril Square
Douglas
Isle of Man
IM99 0XX
United Kingdom
This causes fits when I try to enter it into the US banking system.
If I were you, I'd call Royal Mail and ask them... or look on their website for postcode lookup as a best practice.
There's different types of addresses, and each different type has a slightly different structure. Forward sorting offices have a different postal address structure than a residential home with a street number. What if the house has a name instead of a number? There are so many factors to consider.
Since I moved to Canada I had to do something similar and it's far more complicated than a straightforward residential address which generally has:
Street Number if applicable
Street Number Suffix if applicable
House Name
Street Name
Street Type
Street Direction if applicable
Unit Number for flats, townhouses or other types of building/location
Minor Municipality (Village)
Major Municipality (Major Town/City)
County
PostCode
Country if you include Scotland, Wales, Northern Ireland (and now I noticed Eire)
Then you get businesses that have their own Delivery Route, PO Boxes, Forward Sortation Offices...
It gets complicated in a real hurry.
Best bet - give Royal Mail a call and they should be able to give you information on their standard address templates.
EDIT: Your 3 field method isn't a bad one...particularly. However, data sanitization may be a significant issue using the field setup you have and you may need a fairly complex strategy for making sure that the address entered is valid. It's far easier to sanitize single dedicated fields to make sure input is correct than it is to parse various address tokens out of combined fields.
Another simpler way to gain this info is to go on the Royal Mail website and check their postcode lookup page.
On their main postcode lookup, they use 4 fields and I guess they have some form of validation on the street name/type field. They separate the house number and name and I guess they only allow major municipality. I'm assuming the county/country are assumed. If you break out their advanced search, they give you two extra fields for flat number and business name.
Given that some fields are combined on their site, you have to assume that there's some amount of validation to make sure that data entered can be gainfully used.
Premises elements
Sub Building Name
Building Name
Building Number
Organisation Name
Department Name
PO Box Number
Thoroughfare elements
Dependent Thoroughfare Name
Dependent Thoroughfare Descriptor
Thoroughfare Name
Thoroughfare Descriptor
Locality elements
Double Dependent Locality
Dependent Locality
Post Town
Postcode element
Postcode
This answer may be a few years late, but it's aimed at those like myself looking for guidance on how to correctly format postal addresses for both storing in a database (or the likes of it) and for printing purposes.
Taken from Royal Mail Doc, link below - conveniently titled the 'Programmers Guide'
Technical specififcation for users of PAF
Page 27 - 42 was most helpful for me.
It's very likely that a "UK" will be opened to Eire as well, and in some lines of business there will be legal differences, generally between Scotland / NI / the channel islands and England and Wales.
In short, I would add country to the list. Otherwise it's fine (no fewer certainly), though of course any address is traceable from a building reference, a post code and a country alone.
Where we live in France its just 3 lines:-
myname
village/location name
6 digit postcode followed by post town name in uppercase
Even from UK that's all that is required