为了快速上手小精灵语言，您并不需要了解或者知道结构化查询语言SQL。如果您有一些使用SQL的经验，您就会注意到在小精灵中使用了很多相同的关键字和短语。做为一个简单的例子，下面的例子是如何先在关系型数据库中使用SQL 然后在属性图中如何使用小精灵来统计每个国家的机场的个数。
While it is not required to know SQL in order to be productive with Gremlin, if you do have some
experience with SQL you will notice many of the same keywords and phrases being used in
Gremlin. As a simple example the SQL and Gremlin examples below both show how we might
count the number of airports there are in each country using firstly a relational database and
secondly a property graph.
在关系型数据库中，我们可能会决定把有所有机场的数据都存储在一张称为机场的表里边。类似的的情形（航线图实际上存储了每个机场的大量的数据），我们可以设軒我们的机场表，这样每个机场的记录如下所示：
When working with a relational database, we might decide to store all of the airport data in a single
table called airports. In a very simple case (the air routes graph actually stores a lot more data than
this about each airport) we could setup our airports table so that it had entries for each airport as
follows.
我们可以使用SQL查证明来统计每个国家的机场的数量，如下：
We could then use a SQL query to count the distribution of airports in each country as follows.
我们也可以用下面的小精灵查询语句在航线图中查询。（在本书的后边笔者会解释这句查询表达的内容）
We can do this in Gremlin using the air-routes graph with a query like the one below (I will explain
what all of this means later on in the book).
如果您以前用过SQL， 您熟悉SQL的语法，您会发现小精灵提供了它自己风格的一些构造，但是，再次重申，SQL并不是学习小精灵语言的先导知识。
You will discover that Gremlin provides its own flavor of several constructs that you will be
familiar with if you have used SQL before, but again, prior knowledge of SQL is in no way required
to learn Gremlin.
在使用小精灵语言在图是工作的时候，您会发现一件事，这里没有SQL中的关联join的概念。图数据库天然的避免了join这件事，（因为实体之间已经有联系了）。最核心的原因是：在很多使用场景中，图数据库非常适合于存储和建模网络关系。航线图就是网络图的一个典型的例子。当然社交网络也是一个好例子。网络也可以用关系型数据库来建模，但是您在搜索网络并询问类似的问题在社交网络中“我的朋友的朋友是谁”，或者“从当前位置起飞最多停留两次，我可以去哪呢？” 事情就会变得复杂，需要多次join操作。
One thing you will not find when working with a graph using Gremlin is the concept of a SQL join.
Graph databases by their very nature avoid the need to join things together (as things that need to
be connected already are connected) and this is a core reason why, for many use cases, Graph
databases are a very good choice and can be more performant than relational databases.
Graph databases are usually a good choice for storing and modelling networks. The air-routes
graph is an example of a network graph. A social network is of course another good example.
Networks can be modelled using relational databases too but as you explore the network and ask
questions like "who are my friends' friends?" in a social network or "where can I fly to from here
with a maximum of two stops?" things rapidly get complicated and result in the need for multiple
joins.
举个例子，想像一个，在我们的关系型数据库中再加入第二张表，路线表。它有三列，达表了出发机场、目的地机场和两个机场之间的距离。它所包含的记录如下：（真实的表当然会有上千行记录，下面只是列出一个这张表会是什么样子）
As an example, imagine adding a second table to our relational database called routes. It will
contain three columns representing the source airport, the destination airport and the distance
between them in miles (SRC,DEST and DIST). It would contain entries that looked like this (the real
table would of course have thousands of rows but this gives a good idea of what the table would
look like).
如果我们想用结构化查询语言SQL来写一个查询统计从AUS出发，到AGR,中间转两次机，旅行的路线有哪些时，我们最终写出来的查询如下：
If we wanted to write a SQL query to calculate the ways of travelling from Austin (AUS) to Agra
(AGR) with two stops, we would end up writing a query that looked something like this:
使用航线图数据库，查询可以用下来相当简单的语句表达：
Using our air-routes graph database the query can be expressed quite simply as follows:
增加或者删除一次转机（hop）和增加或者删除一个或者多个out()步骤一样简单，这比在SQL查询中增加join子句要容易多了。在有着大数关联数据的网络中，查询会越来越复杂一样，SQL查询会越来越难写，这是因为小精灵查询语言设计的初衷就是在这类网络数据中工作，它表达遍历和查询是非常简单易懂的。
Adding or removing hops is as simple as adding or removing one or more of the out() steps which is
a lot simpler than having to add additional join clauses to our SQL query. This is a simple example,
but as queries get more and more complicated in heavily connected data sets like networks, the
SQL queries get harder and harder to write whereas, because Gremlin is designed for working with
this type of data, expressing a traversal remains fairly straightforward.
在小精灵中我们可以更进一步，使用repeat来表达三次转机的概念，查询语句如下：
We can go one step further with Gremlin and use repeat to express the concept of three times as
follows.
小精灵语言还有一个“repeat ... until”结构，我们会在本书的后面见到它。在与emit步骤一起使用时，repeat 提供了一种返回源点和目的点路径的方法，不论从源点需要多少跳到达目的点。
Gremlin also has a repeat … until construct that we will see used later in this book. When combined
with the emit step, repeat provides a nice way of getting back any routes between a source and
destination no matter how many hops it might take to get there.
重申一下，不要太担心这提到的一些小精灵的步骤或者感到困惑，后面我们会一点点的详细学习它们。到此我们需要知晓的是：对于有大量联系的数据，图数据库提供了很好的存储数据的方式，小精灵查询语言提供了优雅简洁的天然的高效遍历访问这些数据的方式。
Again, don’t worry if some of the Gremlin steps shown here are confusing, we will cover them all in
detail a bit later. The key point to take away from this discussion of SQL and Gremlin is that for data
that is very connected, Graph databases provide a very good way to store that data and Gremlin
provides a nice and fairly intuitive way to traverse that data efficiently.
另一点需要注意的是，图中的每个顶点和每条边都有唯一的ID。这不像在关系型数据库中，您可能需要决定是否在表中设置一列ID列，这个在图数据库中不是可选的。有时候用户可以提供或指定ID，更常见的是图数据系统会在顶点或者边首次创建的时候自动生成ID。如果您熟悉SQL，您会认为ID是某些查询的主键。每个顶点和每条边都可以通过ID来访问。和关系型数据库一样，图数据库也有索引，顶点或者边所包含的任一个属性都可以加入到索引中，可以用于高效的查找实体。在大型的图数据库实践中，这样做可以极大的提高搜索您所需要的信息的速度。我们会在“在ID上工作”一节中，更深入的研究ID。
One other point worthy of note is that every vertex and every edge in a graph has a unique ID.
Unlike in the relational world where you may or may not decide to give a table an ID column this is
not optional with graph databases. In some cases the ID can be a user provided ID but more
commonly it will be generated by the graph system when a vertex or edge is first created. If you are
familiar with SQL, you can think of the ID as a primary key of sorts if you want to. Every vertex and
edge can be accessed using its ID. Just as with relational databases, graph databases can be indexed
and any of the properties contained in a vertex or an edge can be added to the index and can be
used to find things efficiently. In large graph deployments this greatly speeds up the process of
finding things as you would expect. We look more closely at IDs in the Working with IDs section.
浙公网安备 33010602011771号