Hi Andy, 
having several edge collections can be an advantage if you don't always 
want to include all of them in a query, since FILTER has to look up 
documents matching the queries, but if you ommit the edge collection in a 
query you can skip that FILTER.

Otoh, there is a limit of collections concerned in one AQL query. 

Each collection has management overhead, but that shouldn't limit you in 
the lower 2 digit numbers.

You should however also consider whether document features may be a valid 
aproach to skip the graph feature alltogether: adding an sub object with 
i.e. the postal code may be what works best. 
Filtering on document attributes is for sure cheaper than doing a graph 
query in first place.

Regarding naming conventions, at least inside of ArangoDB we use 
lowerStartingCamelCase as in .js

Cheers, 
Willi

On Wednesday, June 15, 2016 at 6:40:02 PM UTC+2, Andy Barilla wrote:
>
> My main question is whether separate collections affect performance in a 
> positive or negative way. The IMDB example database has everything in one 
> vertices collection with a type with all the relationships in another 
> single collection. I'm leaning towards separate collections per type. For 
> example, PostalCode, City and Business. However, what about Edge 
> collections? The structure in this case would be 
> (PostalCode)->[LocatedIn]->(City)<-[LocatedIn]<-(Business). But should the 
> two types of LocatedIn relationships be stored in separate Edge 
> collections? Is this just a design concern or would it have a performance 
> effect?
>
> I'm also curious about naming conventions. I was wondering if there have 
> been common or best practices that have developed. You know, the Arango 
> version of Pythonic. Arangonish?  All lower case with underscores? Camel 
> case? Singular? Plural? I know it doesn't really matter. Just wondering.
>

-- 
You received this message because you are subscribed to the Google Groups 
"ArangoDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to