I'm working on an upgrade for an existing database that was designed without any of the code to implement the design being considered. Now I've hit a brick wall in terms of implementing the database design in code. I'm certain whether its a problem with the design of the database or if I'm simply not seeing the correct solution on how to what needs to be done.
The basic logic stipulates the following:
Users access the online trainings by way of Seats. Users can have multiple Seats.
Seats are purchased by companies and have a many-to-many relationship with Products.
A Product has a many-to-many relationship with Modules.
A Module has a many-to-many relationship with Lessons.
Lessons are the end users access for their training.
To muddy the waters, for one reason or another some Users have multiple Seats that contain the same Products.
Certification takes place on a per Product basis, not on a per Seat basis.
Users have a many-to-many relationship with lessons that stores their current status or score for the lesson.
Users certify for a Product when they complete all of the Lessons in all of the Modules for the Product.
It is also significant to know when all Lessons for a particular Module are completed by a User.
Some Seats will be for ReCertification meaning that Users that previously certified for a Product can sign up and take a recertification exam.
Due to Rule 11, Users can and will have multiple Certification records.
Edit: When a User completes a Lesson (scores better than 80%) then the User has (according to the current business logic) completed the Lesson for all Products and all Seats that contain the Lesson.
The trouble that I keep running into with the current design and the business logic as I've more or less described it is that I can't find a way to effectively tie whether a user has certified for a particular product and seat vs when they have not. I keep hitting snags trying to establish which Products under which Seats have been certified for the User and which haven't. Part of the problem is because if they are currently registered for multiple of the same Product under different Seats, then I have to count the Product only once.
Below is a copy of the portion of the schema that's involved. Any suggestions on how to improve the design or draw the association in code would be appreciated. In case it matters, this site is built on the LAMPP stack.
You can view the relevant portion of the database schema here: http://lpsoftware.com/problem_db_structure.png
What you're looking for is relational division
Not implemented directly in SQL, but it can be done. Search google for other examples.
After a quick look at the schema I think one of the things you can do is create a 'to_be_certified' table. Populate it with user_id, product_id and seat_id when a product is assigned to a seat (when product_seat_rtab is populated).
On adding a record to the certification_rtab table, delete the corresponding record in the 'to_be_certified' table. This will give you an easy access to all the products which are certified for a users and the ones that are not.
To get rid of duplicate product_ids, you can group by product_id.
You need to make changes to the lessonstatus_rtab table:
CREATE TABLE lessonstatus_rtab (
user_id INT NOT NULL,
seat_id INT NOT NULL,
lesson_id INT NOT NULL REFERENCES lesson_rtab,
accessdate TIMESTAMP,
score NUMERIC(5,2) NOT NULL DEFAULT 0,
PRIMARY KEY (user_id, seat_id, lesson_id),
FOREIGN KEY (user_id, seat_id) REFERENCES user_seat_rtab (user_id, seat_id)
);
Then you can query for each product that a user has a seat for, is he certified? This presumes that the number of lessons he has scored, say, 50% or higher is the same as the number of lessons in all modules for the product.
SELECT p.name, us.user_id, us.seat_id, COUNT(l.id) = COUNT(lu.lesson_id) AS is_certified
FROM user_seat_rtab AS us
JOIN seat_rtab AS s ON (s.id = us.seat_id)
JOIN product_seat_rtab AS ps ON (ps.seat_id = s.id)
JOIN product_rtab AS p ON (p.id = ps.product_id)
JOIN product_module_rtab AS pm ON (pm.product_id = p.id)
JOIN module_rtab AS m ON (m.id = pm.module_id)
JOIN module_lesson_rtab AS ml ON (ml.module_id = m.id)
JOIN lesson_rtab AS l ON (l.id = ml.lesson_id)
LEFT OUTER JOIN lessonstatus_rtab AS lu
ON (lu.lesson_id = l.id AND lu.user_id = us.user_id
AND lu.seat_id = us.seat_id AND lu.score > 0.50)
GROUP BY p.id, us.user_id, us.seat_id;
UPDATE:
I have considering this issue further and have considered whether it would allow things to work better to simply remove the user_seat_rtab table and then use the equivalent certification_rtab table (probably renamed) to hold all of the information regarding the status of a user's seat. This way there is a direct relationship established between a User, their Seat, each Product within the Seat, and whether the User has certified for the particular Product and Seat.
So I would apply the following changes to the schema posted with the question:
DROP TABLE user_seat_rtab;
RENAME TABLE certification_rtab TO something_different;
An alternative to further normalize this new structure would be to do something like this:
ALTER TABLE user_seat_rtab
DROP PRIMARY KEY;
ADD COLUMN product_id int(10) unsigned NOT NULL;
ADD CONSTRAINT pk_user_seat_product PRIMARY KEY (user_id, seat_id, product_id);
ADD CONSTRAINT fk_product_user_seat FOREIGN KEY (product_id) REFERENCES product_rtab(id) ON DELETE RESTRICT;
I'm not really certain whether this would solve the problem or if it will just change the nature of the problem slightly while introducing new ones. So, does anyone have any other criticisms or suggestions?
Related
I have a table of products:
ID, Name, Time, Creator, Owner, Size, Color, ...
I want to ban certain user from certain products. I thought of 2 solutions.
1) I create a table with info about Banned User:
Product ID, User ID, BannedOrNot
2) Add a column for every user to the product table.
ID, Name, Time, Creator, Owner, Size, Color, ..., User 1, User 2, User 3
There I add if user is banned from this product or not.
I know the 1 solution is better. But I have a really incredible amount of queries to deal with every second. So I want to avoid many queries because of performance.
The user does not select a specific product. The script does select the product automatically depending on things like Size, Color etc. But the problem is it does not know if the user is banned from this product or not.
First solution would require to first get all data from the banned list which belongs to the user who is accessing the product table. And then depending on if user is not banned select the entry from product table.
I am using PHP, MySQL if that matters.
I prefer the first solution. Add only a row for each banned user to the table, and add this to your products queries
In the FROM clause
LEFT JOIN banned_table ON (products.id = banned_table.producs_id
AND banned_table.user_id = <current_user_id>)
In the WHERE clause
... AND banned_table.id IS NULL
This only retrieve one row of banned_table if exists and avoid the query results with banned products.
Hope it works fine for you.
You should create a new table with a Foreign Key to products:
Banned(Product -> Products, User)
You can create it using this Queries:
CREATE TABLE banned(product NOT NULL, user NOT NULL, FOREIGN KEY (product) REFERENCES products(id))
You can then get the products for a single user with one Query:
SELECT *
FROM products
MINUS
SELECT p.Name, p.Time, p.Creator, ..
FROM PRODUCTS p LEFT JOIN BANNED b on (p.id = b.product)
WHERE b.user ='YOURUSER'
I'm a bit stuck on using the INNER JOIN concept with mySQL & PHP to call information from two tables. I would consider myself an upper-level beginner in PHP & mySQL, using Dreamweaver to lean on from time to time as well.
What I have is a "Accounts" table with a primary key account_id which is stored to a session when a user is logged in. I have a m2m table which stores account_id and it's production_id. And lastly I have a Productions table with a primary key of (you guessed it) production_id. What I'm trying to do is have it look up all the productions a user is assigned to (via the m2m table) and pull the details for those specific productions, from the productions table itself. I'm assuming using INNER JOIN would be the way to go about this?
Here's what I was trying to execute (note that "sessionaccountid" is setup on Dreamweaver's end to pull the session data already).
SELECT *
FROM Productions
JOIN Accounts Productions Junction on account_id = sessionaccountid
Unfortunately, this is turning up a Not unique table error in mySQL. Any guidance on getting this to lock in right would be appreciated! And of course if you could also explain what I did wrong/how your suggestion makes more sense, so I can write it down for myself, that would also be great!
As it is your current query doesn't follow nether implicit nor explicit JOIN syntax and therefore is incorrect.
Use explicit ANSI JOIN syntax and specify how your tables are related in your query
SELECT a.account_id, a.account_name, p.production_id, p.production_name
FROM Junction j JOIN Accounts a
ON j.account_id = a.account_id JOIN Productions p
ON j.production_id = p.production_id
WHERE j.account_id = ?
Here is SQLFiddle demo
I have a mySQL table entitled users. It has a UID, rating, username, password, etcetera.
My goal is to make a system (tribes) similar to Facebook's friends list. Each user will be able to view the profile of users and add them to their tribe. Each user is the chief of only one tribe, but can be the villager of as many tribes as he/she wants to be. The rating system would take into account all of the tribe's members ratings.
After doing some research on relational database tables and grouping, I am not clear about how I should go about setting up the tables, or the PHP code that would go along with that.
If someone can get me pointed in the right direction, it'd be much appreciated!
EDIT: One of the big problems I foresee is accepting to be in a tribe. I'm not sure how you account for this.
similar to Facebook's friends list. Each user will be able to view the profile of users and add them to their tribe. Each user is the chief of only one tribe
Okay, so you have a User table, and also will need a Tribe table.
Then the relations you're describing are a chief-of, which is one-to-one (one user can be chief of one tribe; one tribe has only one chief), therefore you can either store this within User (chief_of: Tribe) or within Tribe (chief: User).
CREATE TABLE User ...
chief_of integer
Here, chief_of might be a foreign key so that if you delete a tribe, the relevant tuple will have its chief_of set to NULL (a user can't be chief of a no longer existing tribe).
The membership is a bit more complicated because one user can belong to several tribes, and a tribe will have more than one member.
This is a many-to-many relationship and is usually done with a table holding key pairs:
CREATE TABLE member_of (
user_id integer,
tribe_id integer
);
Both fields are natural candidates for foreign keys. Here you can find a similar implementation using Authors and Books.
To indicate that Bob is a member of the Clan of the Cave Bear, you retrieve the ids of Bob and Bears, and insert a tuple in member_of.
To retrieve all members of the clan, you can use a JOIN:
SELECT Users.* FROM Users
JOIN member_of ON (Users.user_id = member_of.user_id)
WHERE member_of.tribe_id =
(SELECT tribe_id FROM Tribes WHERE tribe_name = 'Clan of the Cave Bear');
I think that a shorter version of that ON in MySQL is USING(user_id) (meaning that both tables have an identical column identically named), but in my opinion the ON is clearer.
You can also retrieve a virtual "is_chief" column:
SELECT Users.*, chief_of = tribe_id AS is_chief FROM Users
JOIN member_of ON (Users.user_id = member_of.user_id)
WHERE member_of.tribe_id =
(SELECT tribe_id FROM Tribes WHERE tribe_name = 'Clan of the Cave Bear');
The one user whose chief_of attribute is equal to the tribe id will have is_chief set to TRUE, which is equal to 1, so
SELECT Users.*, chief_of = tribe_id AS is_chief FROM Users
JOIN member_of ON (Users.user_id = member_of.user_id)
WHERE member_of.tribe_id =
(SELECT tribe_id FROM Tribes WHERE tribe_name = 'Clan of the Cave Bear')
ORDER BY (chief_of = tribe_id) DESC, user_name;
will retrieve the users in alphabetical order, except the chief, who, if present, will come first.
As for the acceptance into the tribe, this identifies three states: a user is not in a tribe, a user is in the tribe, a user asked to be in a tribe. The first two are actually two faces of the same attribute member_of. So naturally we might create a new attribute and call it wants_in. It would map to a table identical to member_of.
A chief could retrieve all tuples of wants_in whose tribe_id is equal to his own chief_of (so if it's NULL, meaning he's not a chief, this will automatically return nothing). Then he might see this as a table of checkboxes with user names. When he approves the join, for each approval you delete the tuple from wants_in and put it into member_of.
Or you might decide that "membership" is a state in itself, so that you have a more complex join table
user_id,
tribe_id,
status
where status could be, say,
nothing (there's no (U, T, ?) tuple): user U and tribe T are unknown to each other
100: user U is full member of tribe T
-1 : tribe T has decided that U is not a member and cannot even ask to be.
0: user U wants to be member of T
1-99: user U is a probationary (apprentice) member.
It sounds like you'll need two classes: Villager and Tribe.
Then, maybe a database field called chief_of or something that is null if the person is not a chief, and contains the name of their tribe that they are the chief.
In the classes you can have a getChiefOf() method that can be tested to see if the user is a chief or not.
Alternatively, you could have a table of chiefs, indexed by UID, with the same column that says which tribe they're chief of. A little less efficient but a better structure. A drawback that jumps to mind is if the UID for some reason is changed, two tables would have to be updated, so maybe the first one's better.
For the site I'm working on, I want a user to have the ability to checkmark multiple boxes that represent things he/she might be interested, similar to StumbleUpon. A user would check 'web development' and 'web design' then click 'Submit', which would then store his preferences in a database.
Later, if somebody created a project that was tagged with one of the preferences he selected, that user would get an update. So if I made a new project that said "Building a Website" and checked the category "web development", all users who had "web development" selected on their personal profiles would get some kind of message or email alerting them to the newly created topic.
What is the best way to implement this in MySQL format? I looked at some pages on managing hierarchical data (there will be generalized categories like "Computers" or "Music" and an admin will be able to add/delete/edit categories), but none of the methods seemed to be what I needed - at least, not in the way of thinking I'm stuck in. Perhaps there's an easier answer out there that I've been overlooking?
Create a table containing the various interests. Say
Interests :- id, interest
Then a table which stores all the interests selected by a user as
UserInterests :- user_id, interest_id
And a project interest relation as
ProjectInterest :- project_id, interest_id
Now when a new project is added you can run a query similar to the following onw to get the users that the project is of interest
SELECT DISTINCT user_id
FROM UserInterests ui, ProjectInterests pi
WHERE ui.interest_id = pi.interest_id AND pi.project_id = <new project id>
Or, using the explicit join syntax:
SELECT DISTINCT user_id
FROM UserInterests ui
INNER JOIN ProjectInterests pi ON ui.interest_id = pi.interest_id
WHERE pi.project_id = <new project id>
What you are asking - I think - is how to implement a many-to-many relationship.
The problem is that you can't give a user a list of interests without locking yourself into an exact number of interests they can select.
The solution is a Junction Table. On one hand, you have your list of users, and on the other hand, you have your list of interests. The junction table is a third table that lists the relationship between these two groups.
CREATE TABLE `user_interest` (
userid UNSIGNED INT REFERENCES `user` (userid),
interestid UNSIGNED INT REFERENCES `interests` (interestid),
PRIMARY KEY (interestid, userid)
)
Now you have a list of UNIQUE combinations of users and interests. Let's say you have a list of news articles, each with a single topic ("interestid") assigned to it. Now you can do something like,
SELECT * FROM `article` WHERE `article`.`interestid` IN (
SELECT `interestid` FROM `user_interest` WHERE `userid` = X
)
Which will retrieve the list of articles related to user X's selected interests. First, you get the list of topics that were related to your specified user, then you get the list of articles with matching topics.
I'm writing an online application form and one of the pieces of data I'm trying to collect is the users education history; school name, school city, years they were there and achievements while there. This data could be collected for anywhere between zero to about four different schools and the user will be dynamically adding more fields if required.
My question is how would this be captured within the database since I don't know how many schools the user will be adding? Can it be done in one table, or do I need to create multiple tables and capture the education data in a separate table?
Any help or pointers would be greatly appreciated.
Thanks.
You need separate tables. One with a row per person, and another with a row per school. Schools can be related to people using either a personID in the school table, or an additional table representing the "person attended school" relationship.
Any association of one entity (person) with multiple other entities (schools) requires more than one table.A general rule to follow is one table per "entity", plus additional tables for many-to-many relationships.
Make a separate table for education, and model an "education" in php as a separate class.
The term for this is Normalization. You want to structure multiple tables such that one row of data is succinct, and as little information is repeated as possible. This can be done by figuring out in your head which pieces of information will be repeated, and making a table for that information.
Data between tables is linked via primary keys (hopefully auto increment integers). In this case, you would have two tables: Student and Education. The Student table would have 'StudentID, Name, etc' while the Education table would have 'EducationID, StudentID, SchoolName, SchoolCity, SchoolStudentID, etc'.
Note that Student.StudentID would match with Education.StudentID and can be acquired with the following query:
select Student.*, Education.* from Student left join Education on Student.StudentID = Education.StudentID
In fact, this will have 'SchoolName' and 'SchoolCity' repeating over and over, so this is not fully normalized. To continue, you need to change it a little bit again:
Student: StudentID, Name, etc
School: SchoolID, SchoolName, SchoolCity, etc
Education: StudentID, SchoolID, StudentSchoolID, etc
Note: each student has a different student id at each school they attend - don't confuse this with the auto increment integer 'StudentID'. To get a list in this case:
select Student.*, Education.StudentSchoolID, School.* from
Student left join Education on Student.StudentID = Education.StudentID
left join School on Education.SchoolID = School.SchoolID