I've got a few days left before I need to hand in my relational database and everything's going alright. I have the database itself built but there's one design issue that I just can't figure out.
I need a results table, one that references the Members and the Competitions table but I already have a link table there. I'm pretty sure I've simply managed to mislead myself but hope you guys can help! :)
Since I'm an awkward 2 points away from being able to post an image, an imgur link to the schema itself is located here: http://imgur.com/mgKaQql
Looking at your tables, I think you are looking for either
joining Members-Competitions to Competitions-Prizes, which would give the explicit relationship between the member and the prize that they won in that competition, (This is creating a Members-Competitions-Prizes "link" or relation)
or
adding an attribute to the Members-Competitions relation that would show that members placement in the competition regardless of whether they won a prize. (This is creating a new column in the Members-Competition link/relation)
You choice will depend on what you expect to do with the information.
Related
First time posting. Long time reader!
I've recently started delving into Access. I have some background/slash knowledge with databasing and I've made good progress on my little project - however, I am stumped when it comes to nesting/many one-to-many's. I'm trying to work it all out as an algorithm first, instead of continuing on in frustration. I vaguely remember that in SQL you can have parent and child forms, where the child form each parent is persistent. Is that the same with MS Access Subforms?
Maybe its a limitation of Access, or maybe I'm just a muppet noob - so I'm hoping someone can point me in the right direction!
Scenario:
Let's consider a building/office: This building has Doors and Rooms. For the sake of the question, let's only consider the Doors and Rooms.
In my scenario, a Room can have multiple doors, whereas a Door can only have a maximum of two Rooms (the two rooms that it joins).
I have a table of Doors and a table of Rooms, each with a PK.
I want to have a list of Doors, that demonstrates what Rooms they are associated with (should only ever be two) and I also want a register of Rooms, that lists all Doors associated with the Room.
Problem 1: So considering the Rooms scenario, how would I associate it with the Doors Table, in such a way that I can have multiple entries linked to the Room Table. I'm assuming a join them through a third table that links Rooms and Doors.
Problem 2: In relation to the Doors scenario, what would be the best way? Would I make two columns/fields in the Door Table, like Room_A and Room_B, or would I somehow join them through a third table?
Problem 3: Further to this, I will need to make a list of all Doors that are accessible in both Room_A and Room_B. I think this part won't be so hard once the two other problems are dealt with.
Before anyone jumps in and says "upload a screenshot you douchebag" - I can't upload anything at the moment. I'll try and upload something later today.
Thanks in advance for any info!
I'm creating a small community using the Symfony2 Framework and backboneJS.
When I took a look at the database today I realized that it might be wrong to store all images using this schema.
ImageTable
Id
Title
Owner
Description
Url
So when a user logs in and wants to have a look at his own images, I just loop through all images where owner == currentuser.
Is this a bad practice?
The more owners I have the longer the query its going to take, right?
I'm asking since it might take a week to restructure the whole website database and I don't want to fix what might not be broken.
I know a solution might be to set a manytomany relationship between the current user table and an own image table, but is it worth the effort?
As far as I can see, this is as normalized as it gets for your scenario. A many to many relationship is not what you are looking for, since a user may have multiple images, but an image can't have multiple owners (or can they?).
So if the Owner is a foreign key for the table user you are good.
Well, I am working on a project which might involve thousands of users & I don't have much experience in databases especially when it involves relationships between entities.
Let me explain my scenario. First there's an User who can login into our system using his credentials. We have a module in our system, which will enable him to create Projects. So that brings a relationship between User table & Projects table.
Now there's another module, namely Team Creation Module, it does what it says. Out of the list of available members, he can pick who he likes and add them to a team. So there are tables for that Members & Team. Furthermore, a member can be a part of many teams and a team can have many members & a "User" can be member as well.
I have a designed the database myself but I am not sure if it is good or bad one. Moreover, I would really appreciate if someone can point me to good tutorials which shows how to insert or update into tables involving relationships.
Here's my design till now:
Update
After a discussion with someone on IRC, I came up with a revised design. I merged "User" & "Members" table as User is also a Member.
My question still remains the same, Am I on right track?
It's great that you're thinking long-term, but your solution won't work long-term.
This is not the first time this sort of thing has been tried before. Rely on the wisdom of those that have messed up before. Read data modeling pattern books.
Abstract and Normalize. That's how you get to a good long-term solution.
At least read up on The Party Model. A group and individual are actually the same (abstract) thing.
Put actually different things in different tables. An Address and Member don't belong in the same table.
"Am I on the right track" is not a useful question - we have no way of telling, because it depends on where you are headed.
A couple of things:
it's a good idea to name the relation columns after the relationship. For instance, in the first diagram, the "owner" of the project should not be called users_user_id - that's meaningless. Call it "owner_id" or something that meaningfully describes the relationship between the project and members table.
in the second diagram, you appear to have a "many to many" relationship between members and projects in the members table - but there's no efficient way of storing the id of more than one project in the members table. You need to factor that out into a joining table - projects_members, for instance, just like you did with teams_members.
the "teams_members" table has a primary key called tm_id. A purist would tell you this is wrong - the unique identifier for that table should be the combination of member_id and team_id. You don't need another unique identifier - and in fact it's harmful, because you must guarantee uniqueness of the member_id and team_id combination.
As Neil says, you probably want to start reading up on this. I can recommend 'Database Systems: Design, Implementation, and Management' by Coronel et al.
I am making a database that is for employee scheduling. I am, for the first time ever, making a relational mySQL database so that I can efficiently manage all of the data. I have been using the mySQL Workbench program to help me visualize how this is going to go. Here is what I have so far:
What I have pictured in my head is that, based on the drawing, I would set the schedule in the schedule table which uses references from the other tables as shown. Then when I need to display this schedule, I would pull everything from the schedule table. Whenever I've worked with a database in the past, it hasn't been of the normalized type, so I would just enter the data into one table and then pull the data out from that one table. Now that I'm tackling a much larger project I am sure that having all of the tables split (normalized) like this is the way to go, but I'm having trouble seeing how everything comes together in the end. I have a feeling it doesn't work the way I have it pictured, #grossvogel pointed out what I believe to be something critical to making this all work and that is to use the join function to pull the data.
The reason I started with a relational database was so that if I made a change to (for example) the shift table and instead of record 1 being "AM" I wanted it to be "Morning", it would then automatically change the relevant sections through the cascade option.
The reason I'm posting this here is because I am hoping someone can help fill in the blanks and to point me in the right direction so I don't spend a lot of hours only to find out I made a wrong turn at the beginning.
Maybe the piece you're missing is the idea of using a query with joins to pull in data from multiple tables. For instance (just incorporating a couple of your tables):
SELECT Dept_Name, Emp_Name, Stat_Name ...
FROM schedule
INNER JOIN departments on schedule.Dept_ID = departments.Dept_ID
INNER JOIN employees on schedule.Emp_ID = employees.Emp_ID
INNER JOIN status on schedule.Stat_ID = status.Stat_ID
...
where ....
Note also that a schedule table that contains all of the information needed to be displayed on the final page is not in the spirit of relational data modeling. You want each table to model some entity in your application, so it might be more appropriate to rename schedule to something like shifts if each row represents a shift. (I usually use singular names for tables, but there are multiple perspectives there.)
This is, frankly, a very difficult question to answer because you could get a million different answers, each with their own merits. I'd suggest you take a look at these (there are probably better links out there too, these just seemed like good points to note) :
http://www.devshed.com/c/a/MySQL/Designing-a-MySQL-Database-Tips-and-Techniques/
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
http://www.sitepoint.com/forums/showthread.php?66342-SQL-and-RDBMS-Database-Design-DO-s-and-DON-Ts
I'd also suggest you try explaining what it is you want to achieve in more detail rather than just post the table structure and let us try to figure out what you meant by what you've done.
Often by trying to explain something verbally you may come to the realisations you need without anyone else's input at all!
One thing I will mention is that you don't have to denormalise a table to report certain values together, you should be considering views for that kind of thing...
I know the title looks a little faque, but my technical english is not as good as would it to be.
My question. I'm designing a kind of work order form with access database. The pretty standard database I can manage, but my problems starts when I want multiple entries for one customer.
For example:
Customer Chris with Id 1 has a problem, he has a BSOD which is fixed. Customer Chris has a new problem some weeks later with his videocard, which will be fixed later ofcourse (;-))
The info above needs to be stored in the access database. Do I need a second table? I really don't have a idea.
You need at least two tables, one for customers and one for problems. The problem table should include such information as customer id, date fixed and fix applied. You may also want to include the engineer, in which case you will also need an employees table, and so it grows.
You may wish to read http://r937.com/relational.html