I'm looking for guidance on the database structure for a multi-regional website.
I am setting up a website, similar to craigslist.com, that will allow users to post adds in their city. I am using a MySQL database.
I want to have regions as subfolders linked to subdomains e.g. ca.mysite.com goes to mysite.com/ca.
My question is how do I manage the database(s) when I want to add another city to my website.
If I use a different database for each city, then users wont be able to login to other cities as their login details are stored in the city they registered at in the users table of it's db.
This may not be an issue though, as the content is city specific, like craigslist.
But, should they wish to contact users in other cities, they wont be able to.
Also, there would be duplicate username's and email addresses overall, as users could register in all of the cities using the same email and username.
If I create a central database with for instance, a users table, and a messages table, and then a separate db for each city with all that cities 'posts' then when displaying basic information I will need to consult the city specific db plus the central db that stores user info.
Alternatively I could store everything on one database, and store the logged-in user's location in a cookie, pass that to a session variable, and use that location as part of the database query when displaying search results etc.
However, would this not add an unnecessary overhead to each query?
e.g. every search would have to have ' AND location = $user_location ' added in.
I really have no idea what would be the best method here.
Thanks in advance for any help on this.
It seems that you still do not know clearly the system you want to build. Before starting designing a database for this system, please make sure that you have the full description of the system requirements. Some sample questions that help you clarify are:
What features does your website offer?
What are all the actions that a user using your system can do? With each action, is there any restrictions?
Some other questions relating to the system performance:
- How many users do you expect to use your system?
- How fast and correct each action should be served? Which actions are used frequently?
It makes no sense to design a system without a careful understanding about the system requirements.
So here is the sample database design and how it can support your requirements.
Cities(cityid, cname)
Users(userid, fname, lname, cityid, currcityid)
Messages(mid, senderid, receiverid, content)
Adverts(aid, title, content, userid, cityid)
When a user switches the city, update the currcityid field in its row in the Users table.
When a user posts an ad on a city, insert a new row to the Adverts table. The userid and cityid of the new row are the ids of the corresponding user and city.
When a user sends a message to another user in the system, add a row to the Messages table. The senderid and the receiverid of the new row are the ids of the corresponding users.
Query all ads in a city: SELECT * FROM Adverts WHERE cityid = $cityid
Query all ads of a user: SELECT * FROM Adverts WHERE userid = $userid
Query all ads of a user in a specific city: SELECT * FROM Adverts WHERE cityid = $cityid AND userid = $userid
Hope this helps.
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
In an application I've been building, I have a users table. The users represent a firm's staff. I also implemented a role/permission system. Permissions are assigned to roles (staff, manager, director, etc.), and roles are assigned to users. Permissions prohibit the use of certain actions in the app.
Now, I'm introducing another user type: customer (will also be able to log into the app). The customer fields are different from the user fields, so I can't store the customer information in users table (and create a role for customers).
(Normally, just creating a customer role for the customers and store the custumers in the users table would be fine, but since the fields are different, I don't think that's an option.)
First, I thought about creating a seperate table for the customers, but I'm not sure if that's okay, because when someone tries to log into the app, I have to check two tables (users and customers) for the log-in credentials. What if I introduce a third user type? Check three tables? That doesn't seem practical/efficient.
So I thought about seperating the log-in credentials from users, and ended up with three tables:
users will hold log-in credentials
staff will hold staff meta/profile information
customers will hold customer information (same as staff)
This way, I can introduce many different types of users. And if I know what I'm looking for, I can get the record. For example, say I want to get/query a staff, I can just do:
SELECT * FROM staff
JOIN users USING (user_id);
The problem is how do I query users when I don't know what I'm looking for? I mean, the logged user can be a staff, customer, etc. I need to do something like this:
SELECT * FROM users
JOIN [specific_table_name] USING (user_id);
How do I know which type of user just logged in? I could store the user type (the target table name?) in users, but will it help in a (single) query? I mean, find the user in users (using credentials), and then join the user information from another table (staff, customers, etc.)?
Currently, I'm thinking about doing two queries. First is to get the user (credential) record, and the second is to get user (say, profile) information (using a field type from user record).
Of course I'll be doing this in PHP. For example (not real code):
$email = "someone#example.com";
$user = get_user($email); // SELECT * FROM users WHERE email = "someone#example.com"
switch ($user["type"]) {
case "staff":
$user = get_staff($email); // SELECT * FROM staff JOIN users USING (user_id) WHERE email = "someone#example.com"
break;
case "customer":
$user = get_customer($email);
break;
// ...
}
// how it's done doesn't really matter. the thing is "type" needs to be checked to get the corresponding user info
Is this best way to handle this? Is there a way to make the queries in SQL (without resorting to PHP)? Like JOIN after WHERE? Or make two queries in one (save the first query result, and use a column value from the first result as a table name in the second query)?
Mentioned tables:
I'm still researching, and I found out that what I'm doing with the tables is called (?) "Class Table Inheritance". It seems clever for non-login related entities (when going from child to parent; e.g. staff -> user), but in reverse (parent to child, e.g. user -> staff|customer|etc.), it seems problematic. Since I figure these things as I go, I'm stuck at the moment.
One solution that just (while typing) occured to me is to use different log-in forms/pages specific to user types. The form/page could let me know the user type beforehand, but I rather not use this method. So, single log-in form for all users.
I'm calling users as the base/parent table, and the stuff, customers, etc. as the child tables, because first insert happens at users, and child tables use user_id from users.
You could create a union and use an alias in the query to define different fields mapping for the same name, if there is no field in one table you just cast the alias for an empty field:
SELECT (staff.name) as name FROM users
left JOIN staff USING (user_id)
UNION
SELECT (customers.first_name) as name FROM users
left JOIN customers USING (user_id);
If the userId is a PK/FK it will be only returned by one table.
I would set all users login info and email to the parent table (customers and staff) and two tables with foreign id key for other data, with users.type as you suggested. It could be done with one query, too and Switch condition is not needed:
SELECT users.email,users.type,staff.field2,customers.field3 from users
LEFT JOIN staff ON(users.type='staff' and users.id=staff.uid)
LEFT JOIN customers ON(users.type='customers' AND users.id=customers.uid);
This is a fictitious example to try to illustrate some design choices I have...any thoughts or links deeply appreciated.
Imagine we have a MySQL database with a table (call it libTBL) that contains a row for each book in a library.
This table will be updated, by admins, as new books are added.
Users will be able to create a library of such books - that is, a list representing THEIR selected books.
Users can add a personal, private comment to each book and other meta data (when they started reading it, a review etc).
Users can also add their own books, but these books should not appear in the libTBL table.
What are best practices for capturing this user data?
When a user is created, create a row in a new table, with each book in the libTBL represented, so IF the user adds notes or other data we already have a home for it?
Create a new row in a user library table only when they make a note on a specific book?
-- One use case, though, is a user ordering their subset library...which would require a new row for each book they order (or all of them, depending on how ordering was implemented).
Use bookID and userID to query a user table for custom values for a particular book?
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
What's the correct way to implement the below concept via MySQL and PHP? Say a website has two groups/communities, both of which allow its users to ask Questions, answer Questions, and start Discussions, pertaining to the respective community. A user will choose which community he/she wishes to enter via below code(main.php):
<h2>Group A</h2>
<h2>Group B</h2>
After the user clicks on say Group B, he/she will of course be directed to groupB.php, where he/she will be able to view the data related to the Group B community (Questions, Discussions posted by the users etc. ). Of course, one will also be able to do the same for the Group A community.
Now my question is: How can I do this efficiently in MySQL? As of now, say if the user wants to create a discussion/question in Group B, which is located on groupB.php, he is directed to a form(discussion.php). Tiny code below:
<form action='savedisc.php' method='post'>
The above form will be available in both communities, i.e. groupA.php and groupB.php. Therefore, of course, savedisc.php will save the content of the form to a database. Meaning, discussion.php and savedisc.php will help in saving both groupA.php and groupB.php's contents. Some of the savedisc.php is below:
$sql="INSERT INTO GroupA (Message, Title, Type)
VALUES
('$message','$title','$represents')";
Where GroupA is the Table's name. The Table name will change of course respective to which group the user may be interacting in. So for group B, the above code will look the same but GroupA will be replaced by GroupB. How can I do this in savedisc.php? Will I have to use numerous IF statements for various groups?
Given the above steps, is this even possible? Can discussion.php be located on all community pages? Because then, savedisc.php's job would be to save contents of groups A, B, C, D in their respective tables within the same database, but the respective group's table. Am I even on the right track?
Thank you.
You will want to spend some time research relational databases; however, here is a quick high-level answer.
You want to have a few tables: users, groups, groupmems, questions, answers.
users (id, username, group*) -- just an idea and not needed necessarily
groups (id, name)
groupmems (id, groupid, userid)
questions (id, Title, Message, Userid, groupid, date)
answers (id, questionid, title, message, userid, date)
What you do is make it where these tables relate to each other through the existence of auto-incrementing primary keys. If you choose to have users login then you will need the users and groups tables for greater flexibility. If you choose not to, then when a user wants to post a new question or answer you will use the PHP POST method to send the value of the group id to the form, which will be bound to a hidden text field.
that's very easy
there should be only one table with group field.
so, you have to have only one set - one form, one script, one table. just pass group identifier using query string and hidden input field