As the title states, I need to tell grails GORM that a domain class has a many to many relationship to itself.
In my system, I have a class "course", this "course" class can have none, one or many correlatives.
Taking the example:
mathematical analysis 2
To be able to take the mathematical analysis 2 course, you need to have approved mathematical analysis 1 and physics courses.
mathematical analysis 1 does not have any correlatives or courses to be approved to be able to anyone to take the course.
I have the following:
class Course {
String name
static hasMany = [correlatives: Course]
static belongsTo = [target_course: Course]
}
But it does not seem to have the impact in the Data base that I expect.
Im expecting to have a course_course table that has the many to many to itself like the following:
course_course
int id_course_course
int id_correlative_course
int id_target_course
Am I missing something important here?, help please!
You don't need a many to many table to represent that. While each Course may "have many" correlatives, each correlated course only has one parent.
This is sufficiently represented by a single table like (heavily depending on any mappings you specify):
course:
id (int)
name (varchar)
target_course_id (int, nullable)
Related
I have difficulty understanding this statement in DL:
∃R.∃S.C(a)
What does this proposition exactly mean?
Thanks in advance!
This means that the individual named a belongs to the concept ∃R.∃S.C. The concept ∃R.∃S.C represents the class of things that have a relation R with something that has a relation S with something that is in the class denoted by C. For instance, if R is the relation married to, S is the relation works for and C is the class of Public organisations, then ∃R.∃S.C represents all the entities that are married to something (or someone) that works for a public organisation. Then ∃R.∃S.C(a) means that the individual named a is such an entity.
I'm new to Neo4J and I have a question about the most appropriate data model for a the problem domain described below.
Background
As I understand it, in Neo4J every relationship has a direction of sorts, outgoing, incoming or undirected. I read that a common mistake newbies make in "bi-directional" relationships is that they might model the relationship in both directions where in reality one undirected relationship would serve the purpose well. I also understand that irrespective of the direction it is possible at query time to ignore it and query based on either side of the relationship.
Problem Domain
This is a bit cliché, but stick with me, in a graph where "People" can connect with one another I felt tempted to model that as an undirected relationship. However, perhaps in my problem domain I want to store meta data on the relationship edge rather than at either of the People nodes. E.g. timestamp of when then connected or type of relationship (friend, family, employer etc...). Perhaps this is a "side effect" of using the spring-data-neo4j libraries but it seems that if I wish to data meta data on the edge rather than at the node I must create a class which is annotated as #RelationshipEntity rather than #NodeEntity. This necessitates a #StartNode and #EndNode which then seems to imply a direction to my otherwise undirected relationship...
Now, as it turns out this might not be a bad thing in my case because perhaps after all it turns out there is something useful about this additional directed context (e.g. perhaps I want to know who initiated the relationship so that the target node (person) must accept the invitation to be friends).
Now imagine that each person can place the "relationship" into a "group" like "friends, family, colleagues" etc I feel like I'd now need to actually have two distinct edges that point in either direction so that the meta data specific to the given direction has a natural place to reside. But this seems to have been described as a newbie anti-pattern.
Questions
I have two questions:
1) Should I use two separate distinct relationship edges that essentially point either way as a bi-directional relationship if I need to store meta data that is specific to the direction. e.g. Person A <--> Person B but person A placed Person B in the friends group whereas Person B placed A in the colleagues group.
2) Given the Java data model below, I am unclear what the direction attribute on the #Relationship annotation of Person should be. If I specify nothing it default to OUTGOING. But since it's a reflective relationship depending on which person instance you look at the relationship could be either outgoing or incoming, e.g. if person A adds person B, both are Person instances, but the direction is outgoing on the person A instance and incoming on the person B instance. Should the annotation be omitted altogether since I'm using a #RelationshipEntity?
Java Data Model
#NodeEntity
#EqualsAndHashCode(of = {"id"})
#NoArgsConstructor
public abstract class Person {
#GraphId
private Long id;
... other attributes
#Relationship(type = "CONNECTION_OF", direction = UNDIRECTED)
private Set<Connection> connections;
}
#Data
#RelationshipEntity(type = "CONNECTION_OF")
public class Connection {
#GraphId
private Long relationshipId;
... other meta-data
#StartNode
private Person from;
#EndNode
private Person to;
}
1) The rule of thumb that works well is to answer a question - if a relationship from A to B exists, can another relationship from B to A still be created, with different metadata? And can you delete one direction of the relationship independently of the other?
If the answer is yes they go for two directed relationships, otherwise stay with UNDIRECTED, and create initiatedBy=userId property or similar.
For your case where you put connections into groups - the thing is that you really categorize the people from another person's view, maybe it is a completely different fact independent of the CONNECTED_TO relationship?
You could e.g. create a group node and link that to owner and all people in the group, with following schema:
(:Person)-[:OWNS]-(:Group)-[:CATEGORIZED]-(:Person)
2) Keep the #Relationship(type = "CONNECTION_OF", direction = UNDIRECTED). For a given person X the connections Set is going to have elements that have from=X for outgoing edges mixed with elements that have to=X for incoming. All of these will be mixed in one collection.
From reading the docs in Grails I found the following statement:
However, excessive use of inheritance and table-per-subclass can
result in poor query performance due to the use of outer join queries.
In general our advice is if you're going to use inheritance, don't
abuse it and don't make your inheritance hierarchy too deep.
My question is: how deep is too deep?
Will 5 extensions in an inheritance chain make Grails cry?, 10?, 20?... what is the criteria to determine this?, or do we know if there is a clear way to extrapolate such performance degradation?
How deep is too deep? is a rather subjective question. But, it's possible to make an educated guess when you consider what happens at the database level with table-per-subclass inheritance. Lets assume you have these domain classes:
class Employee {
String firstName
String lastName
static constraints = {
}
static mapping = {
tablePerHierarchy false
}
}
class Supervisor extends Employee {
String office
static constraints = {
}
}
You'd end up with two tables: EMPLOYEE and SUPERVISOR. The EMPLOYEE table would contain the columns id, first_name, and last_name. But notice that the SUPERVISOR table would only contain the columns id and office.
This means that to retrieve a Supervisor GORM has to join both tables in order to populate the inherited properties.
SELECT EMPLOYEE.ID, FIRST_NAME, LAST_NAME, OFFICE
FROM SUPERVISOR INNER JOIN EMPLOYEE
ON SUPERVISOR.ID = EMPLOYEE.ID
It's these joins which have the potential to result in reduced performance. As you can imagine, 10 or 20 levels of inheritance would be disastrous. Yet a few, especially if the tables are small, would likely be OK.
Besides, a deep inheritance hierarchy is a sign that something is probably wrong with the domain model architecture (ie. consider using Traits).
You can read more about both forms of inheritance in my article here.
I am making a classifieds website in rails 4.1 and am wondering which would perform better for searching given tens or hundreds of thousands of records; one class with 50 fields or multiple smaller classes with inheritance. A typical Object Oriented approach would certainly work here and I would lay it out like this.
The base class would be Posts and would have fields like: Price City Description User Category Condition Buying or Selling Flagged Inappropriate Sold, etc.
The child classes would be things like:
Automobiles: with fields like Year Make Model Color Transmission Drive Type etc
Housing: with fields like: Number of rooms Housing Type Private / Shared Floor # etc
Computers: with things like: Notebook/Desktop RAM HDD size Screen Size etc
And you could imagine other fields for things like:
Clothes:
Jobs:
Phones:
So as I said earlier typically I would approach this from an object oriented perspective but from a performance perspective, would a single table be faster? Note: The user will be both searching through all types of posts and also through specific categories of posts. So on the homepage a user might search for "2004 Toyota 4runner" without specifying a category but they might also click on Automobiles and then type in their search.
Also in case you are wondering why I am making such a project, I live in an undeveloped country where nothing good like this exists :)
Thanks,
I'm new to ASP.NET MVC, so please pardon me if I mentioned wrong terminology on my question
I'm trying to create a soccer related application. Right now I'm trying to design the database / class structures for my application. However I run into a problem when I'm trying to define an appropriate class structure / business logic to represent a soccer match.
On every match 2 teams commonly play, and each team has different attributes (e.g. numbers of red cards, yellow cards and goals it receives), my question is how could you or would you define that business rule in your entity framework structure?
Would it be appropriate for me to use inheritances relationship between those classes?
Here is what I've currently done:
Match Class with these attributes:
MatchID
Date
HomeTeam
AwayTeam
HomeGame
MatchID
TeamID
YellowCards
RedCards
Goals
AwayGame
MatchID
TeamID
YellowCards
RedCards
Goals
My question is what sort of relationship should I used to represent such business logic, perhaps inheritence, or would it be appropriate to use collection of class (Many to many relationship) instead?
I will gladly appreciate your input and/or suggestion
Thanks heaps!
HomeGame and AwayGame doesn't differ at all, so why to differ them on class/database structure level? I would use the same class here (let's call it GameAppearance for example) and just have two differently named properties of that type in Match class. No need to inherit anything here.
Match:
MatchID
Date
HomeTeam (of type GameAppearance)
AwayTeam (of type GameAppearance)
GameAppearance:
MatchID
TeamID
YellowCards
RedCards
Goals