I wonder can we make many relations between one table and many tables with many records in these tables?
For example;
I have a news table, that news can be mapped with Games, Developers, Platforms at the same time with multiple records.
Sample :
News : Crysis 55 pre-order available
Relations :
{Games:Crysis 55; Developers:Crytek; Platforms:Ps3,Xbox360,Pc,Wii;}
I really could not imagine how to be orm design.
OneToMany, ManyToMany?
Waiting for your great helpings.
ManyToMany will be the best fit for this. You could create 4 tables. One table for each (News, Games,Developers,Platforms). News will be your primary table that will contain foreign keys from games, developers, platforms.
This probably would help you in doctrine mapping.
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html
Related
I am just confused about One-One relationship and Many-Many relationship. Well if I have a users table and a course table, Do I have to add a third table to make it Many-Many relationship or I can just connect them with foreign keys and primary keys? I hope my question is clear to you.
One-to-Many example :-
Many to One example :-
Teacher teaches students is one to many relationship
And students learning from the teacher is many to one relationship
May be your dought is clear now!!
You are asking about many to many relationship. In this imaginary relation you have to follow following steps
1-create two tables(users,courses)
2-make third table which is called pivot table . that will contains the foreighn keys of both tables that shows the relation b/w two tables.
3-You also have to make relationships of one-to-many in both tables(users,courses).
I hope this helps if not visit this link you will understand.
https://onlinewebtutorblog.com/laravel-8-many-to-many-eloquent-relationship-tutorial/
I'm having a hard time modeling a certain scenario without having to appeal to more than one request.
Think about a People table, each Person can be related to eachother n times, and this relationship has a description.
Consider the following modelling :
As you can see, I have two People, and person_0001 is child of person_0002.
Now, in this case, if I want to get all relationships that person_0001 has, it's easy, I just query :
GET WHERE PK = "person_0001" AND SK.BEGINS_WITH("rel")
But, since it is bidirectional, how can I get the relationships person_0002 has?
I could use a GSI that inverts the keys, so with one request I can simply query both tables at once.
But real problem comes when I need to update/delete, How can I delete/update all relationships person_0002 has with only one request? I can only read from GSIs.
It's a big difficulty I have in general, what do I do when I need to do a delete/update/write on a GSI?
I design my firebase structure and I'm not sure if that the right way.
Little information:
Each college has some departments.
Each departments has many courses.Courses can belong to several departments.
Each Course has some lessons. lesson can be belong to one course.
I have node of courses with all key courses and information
I have node of departments with all departments and informations.
I have node Course_Departments and Departments_courses
in addition I have courses_lectures and courses_lectures
for display each course learn by some lecturers and each lecturers teach some courses.
so my questions are:
1.How I connect the lesson to these table for example? I want to find all the lessons of the course_key1 that lecture_key2 teach?
2. using with many tables in this way can be take many time to get the data?
for UI I don't want to users to wait much for the data.
Looking at your design, I think, you are on the right track.
I'll give some possible hints of what you can take care of. When designing the structure of a Firebase database design rules of non-relational databases should be kept in mind.
One of them is denormalization. Keep the hierarchy flat! That's an important performance factor for data change listeners since all subnodes are involved. That's what you've done so far.
Relationship of entities can be achied by using the keys. Exactly as you did it in the Courses_Department node. The built-in creation of keys should be used. They should be universally unique.
Here's a good explanation when coming from relational databases.
I have thousands of documents of different types and therefore different fields. My task is to find pairs or a group of documents, with specific relations:
A.race='dwarf' and B.race='elfe' and C.profession='thief'
A.haircolor = C.haircolor and B.favorite_meal = C.favorite_meal
Is there a database which is schema-less and relational?
Having a schema is part of the definition of a relational database, so a database can not be both schemaless and relational.
But when you are searching for a database which is good for modeling and analyzing relations between entities without enforcing a consistent schema, you could take a look at graph databases like Neo4j. These databases focus on defining entities mostly by their relation to other entities. They make it really easy to find entities which have common relations to other entities.
Am making a cube in SQL Server Analysis Services 2005 and have a question about many to many relationships.
I have a many to many relationship between two entities that contains an additional descriptive column as part of the relationship.
I understand that I may need to a bridge table to model the relationship but I am not sure where to store the additional column - in the bridge table or elsewhere?
Many To Many relationsip in SSAS can be implemented via an intermediate fact table that contains both dimension key that subject to the relation.
For example; If you have a cube that has a book-sales-fact table and you want to aggregate total sales by author (which may have many books and a book may be written by many authors) you should also have a author-book intermediate fact table (just like in relational database world). In this bridge table, you should have both dimension keys (Author and Book) plus some measure related to the current book and author such as wages paid to the author to write the book (or chapters).
As a result, if your additional column is kind of a measure you should add that column to the intermediate fact table.