I'm currently building a professional network and although I have manage to get the overall DB structure and data entry figured out, I continue to struggle with how I should build my location table or tables and then how best to query that data to display on a users profile or to be searched upon.
Currently I have a single locations table and that is as far as I have got.
I'm looking for advice on how best to proceed before I invest too much time building something that may prove difficult to manage down the line or which will not work.
UPDATE: to clarify the location data I wish to store and in what format; A user can set a city and country of residence but can specify other cities and countries where they can work. So, in short a user has a primary location and then possibly several locations they can be.
Currently I am only looking to store specific City, County and Country information. I do not want it to be possible for a user to specify their own location by free-typing. It would be beneficial if I could use the table to populate data entry fields too.
However in time I would like to work on developing 'nearby' searching which will require geo location and the story of coordinates.
The project is built in PHP with a MySQL database.
The site works like this;
Users register and create a profile.
Their profile lists info about them, including their location.
Other users can search based on select fields including another
user's location.
The database is currently set up as follows;
User data sits in a users table.
Profile data sits in a profiles table.
Profile photos sits in a profile_photos table.
Gallery Photos sits in a photos table.
Location data sits ???
Any help here would be appreciated.
Related
I have an assignment where I need make a table for users which houses basic information like fname,lname,email...etc but I also need to store information about the users location address,zip,city,state...etc. A user can have multiple location information.
I've been just doing a csv but people are telling its pretty bad to do that so I'm trying to do things the right way.
I was learning about many to many and it seems to do the trick. But the problem is I need to load this data to a table for viewing.
I just don't see anyway that this would work without having to do a query inside the first query.
ie:
while($row=mysqli_fetch_assoc($query)){
$id = $row['id'];
///Get user locations based on id here.
}
From what I understand if we're storing user ID lets say to a table to make the relation to the locations table and a user can have multiple locations would join be useless here?
I need to pull up records 25 at a time so it's not only supposed to pull one. I'm using datatables with the collapse/show so the data needs to be in a separate container
The Approach of storing location separately in other table with user_id column will be good and as the user will be unique let's say he is unique regarding his email, his locations can be fetched.
Other approach, You can store locations(multiple) in form of object and fetch them then you can get individual location by decoding the json
want to create simple access db that will allow entry of customers that do business in multiple states. So be able to create company table with things like company name,email, state but be able to put in multiple states if that company works out of more then one. Say company a is out of Florida, company b is in new york, florida,texas, company c is arizona and florida. once all tables created would then want to be able to query all companies operating in a given state and get list of the companies. so if i queried companies operating in florida, i would get companies a, b and c back in this example. So how best to create the underlying tables and joins/relationships in access to make this work? any example access dbs i could download and use as template would help or a good explaination of how best to setup the needed tables (companies, states,etc) thanks for the help
You simply want to create that main table tblCustomers.
And then create a child table called tblAddress.
In the child table, you can thus enter the address/state/phone number of the company address(s) you have. So you might have one, or 5 such different addresses.
To edit this setup, you thus create a main form with company info etc. You then build a sub form that allows edit of the address.
Then with main form in design mode, simply drop in the form from the nave pane. If you setup the revelations between the tables correctly before doing this, then Access will automatic link up the address for the given company.
So you don’t need a multiple states table, but simply a table that represents the whole address. You as noted might want to include the email, phone number. Thus you can easy enter a company, and then enter address (with state) along with email or phone number for as many locations as you please.
So far, this relation as outlined only requires two tables. The main table, and the table of addresses.
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 working on the data model for a relational database where I have to store User Information as well as User's profile such as Education Level, personal interests, hobbies, and etc. Similar to what most of the social networking sites have or any other systems that allow you to build a profile.
I cannot decide if it would be better to store all this information in one Users table, or break it into 2 tables.
If I would break it into two tables I would have Users table that would just store UserID, Name, e-mail, DOB, gender.
UserProfiles would store the rest of the stuff pertaining to a profile, sharing the same UserID with Users table
If there are multiple profiles of a single user means one to many relation then i would recommend you to create 2 tables one is user and other is user-profile.
If one user have only one profile then your should create only one table with both attributes on User as well as profile.
Go for the more modular design, this will allow for more flexibility and control. The only time I would recommend keeping the data in a single table is if you plan to query the same data frequently.
There is a great article here which goes into depth as to why joins are expensive. You should ultimately base your decision off the information provided in the link, however as I mentioned before if you plan to query the two tables together frequently then keep the data in a single table.
I think,in order to decide which data model to chose, just look at some of the similar requirement Datamodels, which are presented in this Datamodel Library.
Specific to your User-profiles Datamodel Requirement, this link may be useful.
Hope those links will be useful. OR I got this Data model image depicting facebook type data model: