I am building a full stack app, that is kind of like Pinterest or Instagram.
I've gotten stuck, which is a horrible feeling, and I'd love any help I could get from any kind soul out there! :)
So I'm trying to implement the "like" functionality. As y'all know, you can like an entity once, and only once. What I wonder is how to constrain the database in such a way that a user can't like more than once. The way I thought I'd do this is to have a separate Like table like this:
Now of course, if I UNIQUE the user_id, then users can only like one thing on the website, which obviously would be a disaster, hah. So my question is, how do I kind of make sure there are no duplicate rows with exactly the same information in them? Or make some kind of CHECK condition when creating the table so that there can't be more than one row where the user_id and the artpoem_id match?
Or am I thinking about this the wrong way? Should I have like a separate Like table for each and every ArtPoem-entry, and then UNIQUE the user_id?
I would be SO grateful for any help, as this has been bugging me for days. Thank you kindly!
Problem solved! If anyone else sees this in the future, here's how it happened:
With the help of #Solarflare here who pointed me in the right direction, I did this in my ORM (TypeOrm):
Which yielded this raw SQL:
And now my database gives me this error below when I try to add an additional like-table entry with matching artpoemIds and userIds, which is just what I was looking for! Yippie and onwards!
Related
I am new here as well as new in coding. I always get confused when it comes to database designing. Let me try to explain this.
If I need to create a functionality like this (Stackoverflow) website, More specific If I just want simple Question (posting, upvote, downvote) and Answer(posting, upvote, downvote) feature in my website I could follow two approaches.
First
create a table question in which I will save question.
create a table votes in which I will save votes(up and down).
To fetch a question will need to join these two table and get the question and there votes(up and down)
Second
Create a table question in which I will save question and votes count(tow more column to store count up and down votes)
Create a table votes in which I will save votes(up and down).
This time we can get the data from one tablw without join.
I always want to know which one I should use.
I know that in first approach we need to put more joins if we add more feature like (Share,View,Answer,etc).
And if i used second approach we need to take care of consistency and we also need to insert more times as in first approach.
I don't know someone who can answer this. That's why i am asking my question here.
Any help would be appreciated, Thanks.
You will learn a lot by looking at the Stack Exchange Data Explorer.
https://data.stackexchange.com/
In addition to seeing the schema and being able to type interactive queries, you can view, execute, and modify the excellent library of useful queries other people have contributed.
It's a wonderful way to learn from a real-world site.
I'm having a small problem with my code here. Not as much a problem as it's just me that doesn't know how to accomplish this. I'm still new in the rails world. So figured i would ask here before i made a bad McGyver solution.
Anyway, i'm using the Impressionist gem to handle all of my view counts on the various photo entries i have in my database (MySQL)
And i was just wondering if anyone has a good method on how to sort all entries in my database by their view count. The way i see it, i have to compare the amount of impressionable_id's with the id's of their respected entry. However, i'm unsure as to how to go about this.
I just want my photo controller index method to spew out every photo entry it has, but sort it by the amount of views the entries have in the impressions table.
Any ideas?
According to the Impressionable docs, you can add a counter cache to your model. This looks like the best way to achieve this.
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'm about to implement a list of topic/argument in my forum, and I'd like to insert a sort of flag like "read/not read yet" for each message, regard each user in my website.
I think at somethings like this : a table watched_topics with id(INT), user(VARCHAR) and topic_id(INT). When a user watch the page, I'll insert (if the data doesn't exist) these information.
When another user will insert a new message in a topic, I'll delete from the table watched_topics all line with that topic_id.
That could provide a trouble : Think about to 9000 topics and 9000 users that have watched all topics : the table will be so big (9000x9000=81000000).
So, I think is not the best strategy to implement this kind of stuff! Any suggestion would be appreciated :)
Cheers
May I suggest a different approach?
Make use of web browser history mechanism.
Every topic can get a new, unique URL every time a new message is added there. It could include the number of messages, last modified time or a combination of both.
If the user did see the topic, he must have visited it, so a properly set up CSS can help identifying the read ones. You can even use some client-side scripts to modify the behaviour of the page based on that.
Another way to do that would be to keep the watched topics table the way you want to do it, but also store last visit time in user's profile and show all topics as read that haven't changed since that time.
However it's pretty safe to assume that all users reading all topics is very unlikely.
Your suggestion sounds good. I would make user-field also a foreign key - it gives you a bit more flexibility.
Are you sure all 9000 topics are read by all 9000 users? I mean is this reality? Like you said, topic-entries are deleted when new message is added. And when that happens, another 9000 entries are deleted :)
I would index the table and go with your suggestion (with user_id change). If the table size gets in your way, you can always change the implementation later. Most likely it will never be the issue anyway.
For the deletion: you could save what the latest msg-ID was the user saw. This way you do not have to perform a lot of delete actions every time a msg is posted in a much-viewed topic.
I'm new with Doctrine2 so my question can be easy to answer (I hope so).
First of all, here the SQL query that I'd want :
SELECT *
FROM Document
WHERE id NOT IN (SELECT document_id FROM Documents_Folders)
Pretty simple isn't it ? The porblem is that my table 'Documents_Folders' is not an entity. In fact, it was create because I have a many-to-many relation between my entities 'Document' and 'Folder'.
I tried several queries, but none worked.
Thanks.
It really does look pretty simple, so it's not the problem with your SQL.
So if you want some help, tell us what is the error that you get?
BTW Your database shouldn't care what you use Documents_Folders for - it's just a table. (I don't know Doctrine2, but it's still regular database underneath, isn't it?)
Out of curiosity, What is your business case here.
Are you trying to get orphaned documents?
A Document can be part of Many Folders and a Folder can have many Documents?