

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Prefiro usar o personalizado IDs para nó/relacionamento
<a name="best-practices-content-15"></a>

 O Neptune permite que os usuários IDs atribuam explicitamente nós e relacionamentos. O ID deve ser globalmente exclusivo no conjunto de dados e determinístico para ser útil. Um ID determinístico pode ser usado como um mecanismo de pesquisa ou filtragem, assim como propriedades; no entanto, do ponto de vista da execução da consulta, usar um ID é um método muito mais otimizado do que usar propriedades. Há vários benefícios em usar o personalizado IDs - 
+  As propriedades podem ser nulas para uma entidade existente, mas o ID deve existir. Isso permite que o mecanismo de consulta use uma junção otimizada durante a execução. 
+  Quando consultas de mutação simultâneas são executadas, as chances de [exceções de modificação simultânea](https://docs.aws.amazon.com//neptune/latest/userguide/transactions-exceptions.html) (CMEs) são reduzidas significativamente quando usadas para acessar nós, porque menos bloqueios IDs estão ocorrendo IDs do que propriedades devido à sua exclusividade imposta. 
+  O uso IDs evita a chance de criar dados duplicados, pois Neptune impõe exclusividade em propriedades diferentes. IDs 

 O exemplo de consulta a seguir usa um ID personalizado: 

**nota**  
 A propriedade `~id` é usada para especificar o ID, já `id` é armazenada somente como qualquer outra propriedade. 

```
CREATE (n:Person {`~id`: '1', name: 'alice'})
```

 Sem usar um ID personalizado: 

```
CREATE (n:Person {id: '1', name: 'alice'})
```

 Se estiver usando o último mecanismo, não há imposição de exclusividade e você poderá executar a consulta posteriormente: 

```
CREATE (n:Person {id: '1', name: 'john'})
```

 Isso cria um segundo nó com `id=1` chamado `john`. Nesse cenário, agora você teria dois nós com `id=1`, cada um com um nome diferente (alice e john). 