Hi Michael, while I don't have ready-made instructions how to model your use case with a graph and what implication the design may bring with it, I think that you should take a look at our learning material about ArangoDB (not necessarily limited to the graph aspects). Once you know what ArangoDB offers, you can choose the right tool for the job.
For example, another user uses aggregation as first step towards a type of recommendation: https://groups.google.com/d/topic/arangodb/GZ6jG_6OWC4/discussion You can learn about graph basics with our graph course: https://www.arangodb.com/arangodb-graph-course/ More details about AQL graph traversal is in our documentation: https://docs.arangodb.com/3.2/AQL/Graphs/ Especially see the traversal options under the Syntax headline: https://docs.arangodb.com/3.2/AQL/Graphs/Traversals.html#syntax There's also Pregel since 3.2: https://www.arangodb.com/pregel-community-detection/ Also see our performance course however, because it covers the basics about indexing, as well as a comparison of different data models (using the example dataset): https://www.arangodb.com/arangodb-performance-course/ A course specifically about data modeling is definitely on our shortlist and the use case "recommendation engine" was something we thought of already. Don't expect it over the near-term though. *Some thoughts about your data modeling ideas:* Are prices proper entities in such a model? A price feels more like a vertex attribute of places for rent, but you wouldn't want to connect apartments with searching users. Prices as weight attributes of edges seems like an interesting ideas, but wouldn't that as well mean to create a lot of edges between apartments and locations? I guess one could store the actual price in the apartment vertex, and link price *range* vertices to them (so a limited number of price vertices). But is that really required for a fuzzy search? Couldn't you start either with a geospatial search, then filter / limit / sort the results based on price OR filter by price, then sort based on distance? If indexes can be utilized, it should not be a problem to issue additional requests for matches from the next higher price segment, or a larger radius. You could slightly increase the price range or a bit larger search radius than entered by the user to allow for some fuzziness in general, which might already accomplish what you aim for. Regarding locations, are they really point-based? In large cities, you would probably want to search for offers in certain districts, which are rather polygons (with holes?). On the other hand, if you use center point + radius to represent a district geographically, you already add some fuzziness. Best, Simran -- 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.
