When I have two nodes that are connected in both directions, I use two create queries to connect them:
MATCH (london:City {name: "London"})
MATCH (dublin:City {name: "Dublin"})
CREATE (london)-[:Flight {length: 450}]->(dublin)
CREATE (dublin)-[:Flight {length: 450}]->(London);
Since the flight length is the same in both directions, can a two-way relationship be created so that I don't need two CREATE queries?
You cannot create a 2-way relationship, every edge has a direction (although you can traverse an edge in either direction). Given not all airline routes have returns I tend to model such relationships using two edges, in case one day the return trip is removed and you have to travel a home a different way. In terms of creating the relationships, you could create them in one go using the following pattern.
MATCH (london:City {name: "London"})
MATCH (dublin:City {name: "Dublin"})
CREATE (london)-[:Flight {length: 450}]->(dublin)-[:Flight {length: 450}]->(London)
Related
I'm trying to figure out the best way to store graph data structures in an SQL database. After some research, it seems that I can store graph Nodes in a table and just create a join table with the many-to-many relationships between them which would represent the edges (or connections). That seems exactly what I was looking for, but now I want to introduce the users who own the nodes.
From the performance point of view, would it make sense to create a new join table userNodes, or just save users as nodes assuming that node is a generic structure? And what are the implications of storing everything in a single table?
If you have individual attributes that should be stored on a per-node level, then those attributes should be in the nodes table. That is what the table is for.
If the attributes are really a list, then you would want another table. For instance, if multiple users could own a node, then one option would be a userNodes table. However, as you describe the data, there is only one user per node.
I'm designing a database from scratch and I'm wondering if the way I'm using one-to-one relationships is correct.
Imagine I have a table that needs the columns city and country_id, the first being alphanumeric and the second being a foreign key to another table. Should I place these in a locations table and use a one-to-one relationship?
Another example:
I have a table with the factory information of a device like the serial number and other fields. These will later be used to register a device in another table. Of course this is a one-to-one relationship, but should the columns of the first table be in the second table instead? Have in mind that the registrations table has another 4-5 columns.
I've read a lot of times that these relationships can often be omitted. However, I like the separation of concerns that creating a new table can give, in some cases.
Thanks in advance!
This may be a duplicate question, e.g. see:
SQL one to one relationship vs. single table
There's no perfect answer to this question as it depends on use case, but here's the rule of thumb I recommend abiding by: if you can already envision the potential need for separate tables, then I would err on the side of splitting them and using a 1:1 relationship. For example, imagine in the future that you want to have some kind of one-to-many relationship between some new table and the country table, or between some new table and the device table. In these cases you probably don't want city information mixed up with the former, and you probably don't want device registration information mixed up with the latter. By keeping your DB schema normalized, you can better future-proof it and you can mitigate the need for (likely extremely painful) updates that may have otherwise cropped up.
I want to represent a network using a relational schema.
The entities of my network are:
Node : a point on the network.
Arc : a direct connection between 2 nodes
Path : an ordered sequence of arcs.
Is a relational model suited for representing such a network ?
I am considering SQL/No SQL as the options.
The size of my data is not expected to grow at a very rapid pace. I do not want to pick SQL/No SQL based on any predefined query patterns.
Often the best tool to represent a network is a graph database like Neo4j.
But when you want to do it in SQL, both Node (or Vertex in graph theory) and Arc (properly called Edge) would get an own table. A Vertex would contain only the data about the vertex itself, and no information about its relations to others. An Edge would contain the primary keys of the two nodes it links, plus any meta-information about the link itself.
When you need to store paths of multiple nodes, you should use two tables. A Path table with the path-id and any data about the path as a whole, and another table PathVertex consisting of Path-ID, number in that path and primary key of the Edge table which contains all the positions a path consists of.
I want to create a tournament application with cakePHP and I need some help to create Database and linking Models correctly.
My ultimate goal is :
- add/edit/delete teams (i dont need list of players)
- add/edit/delete matchs with 2 teams per match
- display a list of match with results (ex: match5 : TeamAname **2** vs **0** TeamBname)
I dont really know how to organise models and sql tables, for the moment i see 2 tables :
- teams
- matches
Did i need another table between the two tables (ex: matches_teams) or i can use teamA_id and teamB_id in my matches table ? Does CakePHP support multiple foreign keys in same model ?
I want to know if someone has already developed this kind of project in cakePHP, and if it work fine and logically (without tricks).
Thanks!
*> Do i need another table between the two tables (ex: matches_teams) or i can use teamA_id and teamB_id in my matches table?*
You don't need another (association) table, because the only associations you have are the two many-to-one associations between matches and teams given by the two reference columns teamA_id and teamB_id of matches.
In terms of the ontological semantics of the domain of sports, the entity type Match represents an event type, while the entity type Team represents an object type. And for each event of type Match you have two objects of type Team participating in it.
> Does CakePHP support multiple foreign keys in same model?
It would be quite limited if it wouldn't.
We're building a RDBMS-based web site for a federal semantic network (RDF, Protege, etc). This is basically a large collection of nodes, each having a large and indefinite set of named relationships to (and from) other nodes.
My first thought is a single table for all the nodes (name, description, etc), plus one table per named relationship. Any better ideas out there?
On further reflection, two tables total might do, one for nodes (id, name, description), and other for relations (id, name, description, from, to),
where from and two are ids in the nodes table (ints). Still on the right track?
You could optimize the performance by creating 2 rows per relation.
Let's say you have a table Items and a table Relations and that Person A has a relation with Person B. The Relations table has a left and right column, both referring to Items. Now, if you only have one row for this relation, and you want all relations for a certain Item, you would have a query looking like this:
SELECT * FROM Relations WHERE LeftItemId = #ItemId OR RightItemId = #ItemId
The OR in this query will ruin your performance! If you would duplicate the row and switch the relation (left becomes right and vice versa) the query looks like this:
SELECT * FROM Relations WHERE LeftItemId = #ItemId
With the right index this one will go blazingly fast.
No, that sould be fine. Pay attention to primary key and indexes, so that the performance is good.
If you didn't have a single table for the nodes, you'd have to define a lot of relation tables. Each new node type would require a new relation table with every old node type. That could get out of hand quickly.
So a single table sounds best. You can always use a 1:1 relation to extend it, if you need additional fields for certain node types.
if you're using sql server 2008, you might want to consider the new HierarchyID datatype to store your hierarchy in. It's optimized for storage.