I have two tables. One table stores course_updates, which basically has a new row pushed to it everytime someone adds or drops a course. I also have another table follower_updates that has a record pushed to it whenever someone follows someone. I want to be able to get the information for the logged in user, but I'm unsure how I should detect which table the information is coming from being that I want to display the information based upon which table it is from. Should I make a new column that update_type, or should I have a different method?
I'm also going to show what I'm thinking relatively in terms of sql. It won't be perfect because I haven't tested it yet. This is just a sample. I didn't want to bring in my current query because just the course_updates already has three inner joins and an outerjoin, so I tried to streamline the content for this question. thanks!
SELECT * FROM course_updates WHERE (establishes connection
enter code herebetween user and courses and followers)
UNION SELECT * FROM follower_updates WHERE followee.id = currentUser.id etc.
Don't use a UNION. Use two separate queries instead.
Related
I've a mysql table "login" with columns name, userid, pass, email. and another table "info" with columns bio, skills, searchingfor, badge, likes, age
here, the 1st table is used to check login... and the rest is used for storing personal info of an user. but i have a search box where people can search user according to everything except bio & pass. I'm having problem joining the results from two tables so is it ok to put all in one table or is there a simplier way?
and if i put everything in a table would it be heavier for mysql queries to search if the database gets lots of data?
There is no higher load on your mysql server if you combine both tables. This is a valid idea, since it appears that you have a 1:1 relationship anyway, so the code get's easier. Actually the load will be lower, since you do not need a join which is actually very slow in relational database management systems. The performance (load) just depends on your indexes and filter requirements, but that is independent of whether you search in one or two tables.
On the other hand: there is no reason why you should not be able to join those tables as required. So maybe you want to solve your issue here first. And be it just to learn how to do do it ;-)
I've been trying to get this SQL query running for a while now and can't seem to get the last little bit going.
The backend database to all this data is a Drupal install with data spread out across a number of modules, so I need to do a lot of joining to get a certain view table set up that I need for a third-party application.
It's hard to explain the entire schema, but here's the sqlfiddle:
http://sqlfiddle.com/#!2/68df0/2/0
So basically, I have a userid which I map to a profile id through a join. Then I need to use that profile ID to pull the related data about that profile from two other tables. (there should only be one row with each pid in each of the other tables)
So in the end, I would like to see a table with username, othername, and key_id.
I got the first two pieces in there, but just can't seem to figure out how to join in the othername, and keep getting null.
The server is running MySQL.
Thanks guys!
LEFT JOIN other_name
ON profile_link.pid=other_name.pid;
Apologies if this is redundant, and it probably is, I gave it a look but couldn't find a question here that fell in with what I wanted to know.
Basically we have a table with about ~50000 rows, and it's expected to grow much bigger than that. We need to be able to allow admin users to add in custom data to an item based on its category, and users can just pick which fields defined by the administrators they want to add info to.
Initially I had gone with an item_categories_fields table which pairs up entries from item_fields to item_categories, so admins can add custom fields and reuse them across categories for consistency. item_fields has a relationship to item_field_values which links values with fields, which is how we handled things in .NET. The project is using CAKEPHP though, and we're just learning as we go, so it can get a bit annoying at times.
I'm however thinking of maybe just adding an item_custom_fields table that is essentially the item_id and a text field that stores XMLish formatted data. This is just for the values of the custom fields.
No problems if I want to fetch the item by its id as the required data is stored in the items table, but what if I wanted to do a search based on a custom field? Would a
SELECT * FROM item_custom_fields
WHERE custom_data LIKE '%<material>Plastic</material>%'
(user input related issues aside) be practical if I wanted to fetch items made of plastic in this case? Like how slow would that be?
Thanks.
Edit: I was afraid of that as realistically this thing will be around 400k rows for that one table at launch, thanks guys.
Any LIKE query that starts with % will not use any indexes you have on the column, so the query will scan the whole table to find the result.
The response time for that depends highly on your machine and the size of the table, but it definitely won't be efficient in any shape or form.
Your previous/existing solution (if well indexed) should be quite a bit faster.
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 am looking for the best solution for the way the mySQL db should be set up for my app.
My app works like a noticeboard with two sections, "New Notices" and "Seen Notices".
Now when a user has viewed a notice, they click a button and it moves from New to Seen. But ONLY for this person.
Each person will have all of the notices viewable - but not necessarily in the same sections - as users will view them at different times and check them off as seen at different times.
My guess is having one table "Notices" for all notices, and a seperate table called "Seen" with the rows "UserID" and "noticeID". This means that for each notice it will need to consult the "Seen" table to find out if it should be shown or not. Is this ideal or is there another way?
Having a table with NoticeID and UserID is correct, I'd also add viewed date.
You can use 3 tables
Users
Notices
SeenNotices(maybe not the best name)
In the SeenNotices table have three columns UserID, NoticesID, HaveSeen. The have HaveSeen column will tell you if the user has seen it.
The way you are thinking should work, although over time you'll end up with a very big 'Seen' table, which is not scalable. An easy alternative is to use 'Unseen' table instead. This way the table gets smaller as people view the notice and you can also delete very old entries (old notices may no longer relevant so doesn't matter if they are not shown as Unseen to user).
Using the 'unseen' table your query will look like this:
SELECT n.notice_id, n.notice_msg, IF(u.user_id, 'new', 'seen') AS status
FROM notice n
LEFT JOIN unseen u ON (u.user_id = $user_id AND n.notice_id = u.notice_id)
WHERE user_id = $user_id;