SQL Server nested table - sql

Persons: theoretically, unlimited number of persons can be registered in the system. Contact information linked to each person should also be able to be added without limits.
UUID
Name
Surname
Company
Communication information:
Information Type: Telephone Number, E-mail Address, Location
Information Content
Report:
Location information
Most -> Least to be listed by their number of locations
The number of people registered in the directory at that location
Number of phone numbers registered in the phone book at that location
I have 2 tables, how should the relationship be between them and I am confused since the Communication information attribute has 2 attributes in itself. Should communication information be in a separate table?

I would suggest to divide this into three tables:
Persons(UUID,Name,Surname,Company)
CommunicationType(Telephone Number, E-mail Address,)
CommunicationInformation(Person_ID,CommunicationType_ID, ......)

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.

outputing JSON data into SQL table format

link for the database and the JSON file:
https://www.transfernow.net/en/dltransfer?utm_source=20220406hCbu1XIk
download incoming_students.json and iroonwood database from the link above and review the data. We will use these files to dynamically add new students to the Ironwood database.
There are some challenges in this part of the lab to consider:
• You are given the advisor's name in this file, and you will have to derive the ID value (which can be looked up as the instructor ID in the instructor table)
• The same process will need to be followed for looking up the state abbreviation for the provided state name
• The address object will need to be parsed
• The user ID is derived as follows: lastNameFirstInit + number of occurrences in the database. For example, there is Clifford Wall in the database. His userID is wallc1 because there is only one wallc userid. But there is an incoming student in the JSON file that is Candy Wall, so her ID should dynamically come out to wallc2
• A successful import of the JSON file should result in the following student table:
enter image description here
i created 2 seperate tables, one for the Address info, and one for the Student Info,
and i like to know, how can i do the above challenges, so that i can dynamically add the new students into the student table?

How to design table or collection for storing destinations?

I have an task to store data about destinations of delivery, where companies can ship the postal parcel.
The trivial way is to create a table
CompanyShippmentPlaces
id | country | city
There are the some design issues:
What if need be delivered to towns or villages, not to cities? That means altering a table?
What if company needs to specify a part of city, townm or village?
What if the destinations have the same name?
How I plan to use this data:
When system gest a order, the order should be distributes across all companies. I must get all companies that can deliver this product.
It pushes me to use noSQL database, but I am not confident.
What do you think about that?
What if need be delivered to towns or villages, not to cities? That means altering a table?
This would be solved by the solution of jaimish11.
Peronsaly I would change the naming of "City" to "locality" (or something comparable - to generalize).
What if company needs to specify a part of city, townm or village?
I think this is solved by the address lines.
What if the destinations have the same name?
Normaly (as much that i know) each location in a country has it's own pin- or zipcode respectively if the naming doesn't match the post will use the code to identify the location. (to be sure you should ask the post in your at least in your country)
When system gest a order, the order should be distributes across all companies. I must get all companies that can deliver this product.
I would get all locations where the products are available and then get the location wich is next by the city out of the first selection. Maybe you could save the nearest location to a city in your "city table".
The issue you're describing isn't actually an issue. No matter what database you use (SQL or NoSQL) you can simply have all the address fields you need such as:
Address Line 1
Address Line 2
Landmark
City
Pincode/ Zipcode
State
Country
This way, it won't matter whether it's city, town or village.

Phone books and databases : what's the best option?

I am currently working on a development project for which I need to make a database (I will be using Postgre).
Part of that database must store a phonebook for every company, and also for every user. Those two "types" of phonebook are stored in two tables, although they contain the same type of information :
PersonalPhoneBook(IdOwner, IdUser)
//Ids of the owner and a user he's in contact with.
CompanyPhoneBook(IdCompany, IdUser)
//Ids of the company and a user it's in contact with
The personal phonebook will be retrieved with a request like:
SELECT * F
ROM User
WHERE IdUser IN
(SELECT IdUser FROM PersonalPhoneBook WHERE IdOwner = x);
(this request isn't optimized, but you get the gist).
I should also mention that every user and company has as many details (phone numbers, addresses, ...) as they want, thanks to these three tables :
ContactDetail(IdContactDetail, LbContactDetail, ValueContactDetail)
Company_ContactDetail(IdCompany, IdContactDetail)
User_ContactDetail(IdUser, IdContactDetail)
Now there is something that I didn't take in count in that model : the users and companies will want to include in their phone books some people that aren't users in the database.
So I've been exploring several solutions, and I'd need advice to determine which is best:
Making two other tables to store a fixed number of details (2 phone numbers, 1 address) on those "outsiders".
Making all "outsiders" users (but I find that pretty ugly to store them together)
Store an independent phonebook (LDAP-type) for every company and every user (but then data is replicated)
Keep the contact detail system for companies and users and use a LDAP system for the others
Other...?

What is the most flexible design for a table of physical addresses in some variety of SQL?

What is the most flexible design for a table of physical addresses in some variety of SQL? I assume there is something better than { street address, building address, city, state/province/region, country, zipcode }. Also are there standard names for various components of addresses, especially international standard names? Further, what sort of provision should be made for the same physical location having multiple addresses? In what circumstances could this occur?
http://www.upu.int has the format standards for international addresses. Publication 28 at http://usps.com has the U.S. format standards.
The USPS wants the following unpunctuated address components concatenated on a single line:
house number
predirectional (N, SE, etc)
street
suffix (AVE, BLVD, etc)
postdirectional (SW, E, etc)
unit (APT, STE, etc)
apartment/suite number
Eg, 102 N MAIN ST SE APT B.
If you keep the entire address line as a single field in your database, input and editing is easy, but searches can be more difficult (eg, in the case SOUTH EAST LANE is the street EAST as in S EAST LN or is it LANE as in SE LANE ST?).
If you keep the address parsed into separate fields, searches for components like street name or apartments become easier, but you have to append everything together for output, you need CASS software to parse correctly, and PO boxes, rural route addresses, and APO/FPO addresses have special parsings.
A physical location with multiple addresses at that location is either a multiunit building, in which case letters/numbers after units like APT and STE designate the address, or it's a Commercial Mail Receiving Agency (eg, UPS store) and a maildrop/private mailbox number is appended (like 100 MAIN ST STE B PMB 102), or it's a business with one USPS delivery point and mail is routed after USPS delivery (which usually requires a separate mailstop field which the company might need but the USPS won't want on the address line).
A contact with more than one physical address is usually a business or person with a street address and a PO box. Note that it's common for each address to have a different ZIP code.
It's quite typical that one business transaction might have a shipping address and a billing address (again, with different ZIP codes). The information I keep for EACH address is:
name prefix (DR, MS, etc)
first name and initial
last name
name suffix (III, PHD, etc)
mail stop
company name
address (one line only per Pub 28 for USA)
city
state/province
ZIP/postal code
country
I typically print mail stops somewhere between the person's name and company because the country contains the state/ZIP which contains the city which contains the address which contains the company which contains the mail stop which contains the person. I use CASS software to validate and standardize addresses when entered or edited.
The most generic ADDRESS table I constructed included the following columns:
ADDRESS_1 - c/o line
ADDRESS_2 - RR/PO Box
ADDRESS_3 - suite/apt
ADDRESS_4 - street address
ADDRESS_TYPE_CODE - foreign key to ADDRESS_TYPE_CODES table
CITY
STATE_PROVINCE
POSTAL_CODE
COUNTRY
The ADDRESS_TYPE_CODES would be business, home, mailing/shipping, etc.
There's no way to know what address details you're going to get, so you have to make it flexible.
One possibility is, a text field could be used so that the address could be formatted in any way needed. However, then the text would need to be parsed for the parts of the address useful for providing links to maps and directions. Perhaps there should be a text full_address field and then a separate set of columns that will contain parsed (automatically or manually) address pieces useful for links to maps and directions. If the address could not be parsed, a flag would be set saying it couldn't be recognized. (Perhaps this means the address is in a country that the parser doesn't know the address format for, or that the address was entered improperly.)
According to the United States Postal Service:
The components of the delivery address [line] are the primary address number, street name, secondary address identifier, and secondary address range.
Here's more than most people ever wanted to know about the delivery address line for United States addresses.
You would have to look up similar documents for any other countries that you're interested in.
Are you sure you need to be very flexilbe? I usually try and get the simplest design (ie least amount of columns) for the dataset I'm currently working with, then be agile.