I am super beginner of IT and currently studying very basic of ORM before studying mysql.
My question is as the title said, is it possible (correct) if I combine the roles (binary boxes) because they have same roles which is 'studied in'. Actually I'm not sure they are binary relationships. Should I modify as Ternary?
Thank you a lot in advance.
Take a look at this reference image.
Yes you can, it is called many-to-one or one-to-many relations, where A contains multiple instances of B, but B contains only one instance of A.
For further understanding I suggest to take a look at this documentation.
The example is made with an User and a Photo.
Related
I'm not sure whether this question has already been asked in the past.
I'm writing a webcrawler, intended to extract information from multiple websites for promotions,prices and product descriptions.
Which database choice would be ideal to do an in memory comparison on the data of promotions and prices, based on identification of the same product from multiple websites.
I know the design is going to be complex for the Scraper, HTMLDataProcessor and Storage for wrangling. But, I'm looking for a solve for the data layer choice.
Appreciate the help on this.
I'd suggest first you create your object model or Entity relationship diagram for all the entities.(a.k.a ER diagram)
For instance you can see the tutorial here: http://creately.com/blog/diagrams/er-diagrams-tutorial/
Once you have the diagram and relationships between your entity then you can make a choice of whether you need relational database or not.
You need to answer question like:
Do you care about FK (foreign key) constraints?
What is the most common query and do you care about it's performance?
Is an in-memory database sufficient or do you need data to be persisted?
Think along those lines.
I am an unexperienced computer science student and while making projects for different courses a few conceptual questions occurred.
Say I am to develop a website similar to imdb, but for music, from scratch and I want to list some artists on the frontpage.
The database schema is already done with all its relationship and attributes, and there is a table artists.
Should my server-side artist-class contain all table columns and relationships at creation time even it is not necessarily needed at that time?
Or should I construct these objects with minimal parameters (like id, name) and get all the rest when needed (resulting in more individual sql statements) via helper-methods?
I know that there is maybe no definitive answer except for 'it depends' or boils down to personal preference, but maybe there is even a consensus.
If someone could name or link to resources to read up on things like this I would be very grateful, I didn't know what to search for exactly. Thanks.
PS: For people wondering why I don't ask these questions in the CS course; they are mostly held by students/assistants who only had to pass the course and don't have that much experience themselves.
I am not sure what this means so I am answering assuming this does not exist in the question. Will edit answer when clarification is given.
Or should I construct these objects with minimal parameters (like id, name) and get all the rest when needed (resulting in more individual sql statements) via helper-methods?
Actual answer starts here
It does not boil down to personal preference but whether you can or cannot find a practical reason to do something. All design patterns follow practicality instead of personal preferences. Even if there is a consensus you can always ask why.
If there are 100 tables in the database already present and in my web application I can get by with just 2 of them I don't see a reason why I should sit down and create all 100 tables in my web application's domain model. It's just not logical.
There may be some cases when a big application is being created and we are like 99% sure that we will need to model all of it and that requires us to model a bit more classes (say 5 instead of 2) for ensuring that our future work is not hindered.
Also there is the concern of data integerity. Does those 2 tables depend on some other table? Do some table depend on them? If there is a dependency then you might need to include those tables also.
FYI such questions are better suited on programmers stackexchange
I'm planning to decompose an application I started to build as a monolith with a graph database into microservices. But the dilema i'm facing is trying to find a proper solution to split the different services and not loosing the benefits provided by the graph database.
The idea I've considered initially is to split each different entity into it's own microservice, using a document store to persist the data on each service. And then define a higher level service to manage the relationships.
For example with a relationship (A)-->(B), would produce 3 microservices, a service for entities of type A, another for the entities of type B, and a third higher level with a graph database, storing nodes of type A and B, containing only the ID's and the relationships between those.
Question 1: Is there anything wrong with this approach in terms of coupling, fault tolerance, or anything else that I can't think of right now?
Question 2: When you toss a third entity into the game, for example (A)-->(B), (A)-->(C) and (C)-->(B), which one would be the best approach in this scenario?
Do I stick to the strategy of just one higher level service to maintain all the relationships?
Do I generate several higher level services to maintain each type of relationship?
Question 3: In the case of relationships between entities of the same type, for example (Person)--isFriendOf-->(Person), having in mind the concept of separation of concerns, is it appropiate to separate the management of the relationships into a different service?
Any input, feedback and ideas are very welcome.
I've been doing some research on the subject, and for the sake of clarity, I'll propose a more concrete scenario, so it will be easier to discuss about it.
The graph model would be something like this:
The goal here would be to implement a song playlist recommendation service, trying to find the songs that a given user haven't listened yet, based on genres and artists from the songs that the user already listened, and also from other songs listened by other users, followed by the current user.
According to the answer to this question (in Programmers Stack Exchange) How do you handle shared concepts in a microservice architecture? seems that in fact the initial proposed approach is a good one. If separation of concerns is done properly when strangling the different parts into different services, then there shouldn't be coupling issues.
As for fault tolerance, is hard to generalize, so it might be better to study the specifics in a case by case basis, and determine in each situation, how to gracefully downgrade the service when other services aren't available.
Regarding questions 2 and 3, I tried to take a generalized abstract approach at first, but after considering an specific case, I ended up with the conclusion that is also hard to generalize. So for this specific graph model, I came up with this possible solution:
So basically, to question 3 the answer is yes, because this way, the relationship of the users following other users can be used by some other service, and it won't be forced to deppend on the recommendation system.
And to the question 2, it deppends on the domain model, since it made sense to split the user service apart from the friendship service in the first place, that relationship don't need to be replicated in the recommendation service, while all the other relationships are indeed related, it makes sense to keep them together, at least while there is no need to split them again in order to be able to be reused for other services.
I am developing an app that has many-to-many relationship between its entities and also need to store files (pdfs, emails, images, etc). I will be using Java code. I would like to know which NoSQL database to use. I was thinking of using Neo4J for the many-to-many relationship with gridfs to store the files. Has anyone done something like this before? Need to store the complex relationship between entities and also files (which can be huge.. 16MB-1ooMB).
Not sure that i help you, but i try to use mongo for model many-to-many.
And my experience is terrible...
because, official mongo documentation says: for model many-to-many use DBRef.
And when i use DBRef i need dereference my documents references.
And i don't found any working example how to do it....
I wrote own - but it provides many bugs...
Perhaps i'm looser, and don't understand how works with it, but i think when you will be look to mondo think about it.
What are the Tables that would be present in a social networking site (ex: Twitter).
I have a users table as of now. How to keep track of followers and people I do follow?
Should I maintain a separate table for followers and people I follow?
What are the columns which would be there in those tables?
Please don't think this as Subjective/Off topic. As I am a beginner, I thought experts can guide me to get a good DB design?
Try having a look at Database Answers in particular the data models. They have several different designs for various systems. This one is for a social networking site which may give you an idea of what's required.
You may want to search on SO for other social network database questions. I found this one that had a link to flickr showing a schema which appears to be from Facebook.
Your database design will be based around your system requirements. Without knowing exactly what you are trying to achieve, it is difficult to give you the best design.
you can use this Messenger Database Design Concept: Messenger DB
You can create a separate table for follower/ followed relationships. So, when x follow y, create an entry with follower_id = x.id followed_id = y.id.
You can query the relationship table to look for all the users x has relations with by select * from relationships where follower_id = x.id or vice versa.
When/if x un-follow y, you just have to delete the entry you originally created.