I am attempting to make a database to keep a simple menu of items for my favorite restaurants. I have a class for establishments, a class for different menus (like happy hour/dinner/lunch/etc.) and a class for individual items on the menus. Each establishment class has a set of menus and each menu has a set of items.
Is there a single command to reconstruct an entire restaurants menu into a single document?
I'm guessing it has something to do with functions. I have tried messing around with unwind, expand, out, and traverse but I can't seem to figure it out.
Have you tried "fetch plans" in Orientdb.
https://orientdb.com/docs/last/Fetching-Strategies.html
Giving -1 as the depth level will go through the links unlimited and load all the documents to a single doc.
In your case the fetch plan would be something like this.
"select from Establishment fetchPlan *:-1"
Related
In Azure DevOps we need to visualize the parent-child links of Work Items together with their associated Test Cases (through the tested-by links).
With WIQL, the parent-child links can be visualized with tree queries, the tested-by links with dependency queries.
But how do I visualise both parent-child and tested-by links in 1 hierarchical structure? We need such an overview to see which Work Items have associated Test Cases, and at the same time their place in the Work Item hierarchy.
According to your description, I tested the different types of query "Tree of work items" and "work items and directly links", and the results were the same as yours.
Since the query is based on types. Currently there is no option to achieve: visualise both parent-child and tested-by links in 1 hierarchical structure.
You could use "Request a feature" on the left side of Developer Community to open a new suggestion ticket.
I'm having some issues to correctly design the domain that I'm working on.
My straightforward use case is the following:
The user (~5000 users) can access to a list of ads (~5 millions)
He can choose to add/remove some of them as favorites.
He can decide to show/hide some of them.
I have a command which will mutate the aggregate state, to set Favorite to TRUE, let's say.
In terms of DDD, how should I design the aggregates?
How design the relationship between a user and his favorite's ads selection?
Considering the large numbers of ads, I cannot duplicate each ad inside a user aggregate root.
Can I design a Ads aggregateRoot containing a user "collection".
And finally, how to handle/perform the readmodels part?
Thanks in advance
Cheers
Two concepts may help you understand how to model this:
1. Aggregates are Transaction Boundaries.
An aggregate is a cluster of associated objects that are considered as a single unit. All parts of the aggregate are loaded and persisted together.
If you have an aggregate that encloses a 1000 entities, then you have to load all of them into memory. So it follows that you should preferably have small aggregates whenever possible.
2. Aggregates are Distinct Concepts.
An Aggregate represents a distinct concept in the domain. Behavior associated with more than one Aggregate (like Favoriting, in your case) is usually an aggregate by itself with its own set of attributes, domain objects, and behavior.
From your example, User is a clear aggregate.
An Ad has a distinct concept associated with it in the domain, so it is an aggregate too. There may be other entities that will be embedded within the Ad like valid_until, description, is_active, etc.
The concept of a favoriting an Ad links the User and the Ad aggregates. Your question seems to be centered around where this linkage should be preserved. Should it be in the User aggregate (a list of Ads), or should an Ad have a collection of User objects embedded within it?
While both are possibilities, IMHO, I think FavoriteAd is yet another aggregate, which holds references to both the User aggregate and the Ad aggregate. This way, you don't burden the concepts of User or the Ad with favoriting behavior.
Those aggregates will also not be required to load this additional data every time they are loaded into memory. For example, if you are loading an Ad object to edit its contents, you don't want the favorites collection to be loaded into memory by default.
These aggregate structures don't matter as far as read models are concerned. Aggregates only deal with the write side of the domain. You are free to rewire the data any way you want, in multiple forms, on the read side. You can have a subscriber just to listen to the Favorited event (raised after processing the Favorite command) and build a composite data structure containing data from both the User and the Ad aggregates.
I really like the answer given by Subhash Bhushan and I want to add another approach for you to consider.
If you look closely at your question you will see that you've made the assumption that an aggregate can 'see' everything that the user does when they are interacting with the UI. This doesn't need to be so.
Depending on the requirements of the domain you don't need to hold a list of any Ads in the aggregate to favourite them. Here's what I mean:
For this example, it doesn't matter where the the 'favourite' ad command sits. It could be on the user aggregate or a specific aggregate for handling the concept of Favouriting. The command just needs to hold the id of the User and the Ad they are favouriting.
You may need to handle what happens if a user or ad is deleted but that would just be a case of an event process manager listening to the appropriate events and issuing compensating commands.
This way you don't need to load up 5 million ads. That's a job for the read model and UI, not the domain.
Just a thought.
I'm playing around with Postgres and trying to get the hang of more complex issues. Imagine I have a large set of restaurants in each of the 50 U.S. states. Each restaurant contains a menu, and each menu contains a set of items which contain things like price, description, etc. What would be a good way to organize the data?
My initial thought, which I'm sure is way wrong, would be to have a db per state. Within that would be a list of restaurants (and any basic details like address, phone number, rating, etc). Then, I'd have one db per restaurant which represents the menu. This db would contain columns that define each menu entry.
Is this totally off the mark? Is there a more ideal way to accomplish this? My current experience playing around with Postgres has just been limited to a single database.
I'm just looking for a good description, not a bunch of code. This is more a general architectural question. Thanks in advance!
I always recommend you first write down all the individual things you want to store in the database, at the most atomic form that makes sense for your application.
In this example, I am assuming that its a franchise restaurant, and you want to track its various stores and their offerings.
A sample schema:
A table for ingredients, possible columns could be:
Name
Supplier
A table for menu items, possible columns could be:
Name
Descirption
Is Vegan
Has Nuts
Is Kosher
A table that links a menu item with its ingredients:
MenuItemPK
IngredientItemPK
A table for each restaurant:
Name
Owner
Contact Information
A table for each restaurant location:
RestaurantPK
Branch Name
City
State
ZIP
Opening Hours
A table that links a restaurant with its menus:
RestaurantLocationPK
Menu Name (for example, 'weekend dinner')
Menu Descirption
A table that links a menu with its items:
MenuItemPK
MenuPK
Your question is really about relational database design, not Postgresql per se, so that's something for you to track down and learn about.
Your description of your first idea is heading down the right path, except instead of separate databases, these different entities should be stored in separate tables. (You'd break things out into separate databases only when there's no real likelihood you'd ever need to compare the items with each other, or search across all of them, etc. And in your description, these things would all best be in one database.)
I am trying to design a simple application where in I have two entities Notebook and Note. So Notebook can contain multiple Notes.In RDBMS I could have two tables and have One to Many
relationship between them. I am not sure in MongoDB whether I should not take a two collection
approach or I should embed notes in Notebook collection. What would you suggest?
That seems like a perfectly reasonable situation to use a single collection called Notebook, and each Notebook document contains embedded Notes. You can easily index on embedded documents.
If a Notebook document has a 'notes' key, and value is a list of notes:
{
"notes": [
{"created_on": Date(1343592000000), text: "A note."}
]
}
# create index
db.notebook.ensureIndex({"notes.created_on" : -1})
My opinion is to try and embed as much as possible, and then choose to reference another collection via an id as a second option when the reference needs to be to a more general set of data that is shared and might change. For instance, a collection of category documents which many other collections reference. And the category can be updated over time. But in your case, a note should always belong to a note book
You should ask yourself what kind of queries you will need to run on it. The "by default" approach is to embed them, but there are cases (that will depend on how you plan on using them) where a more relational approach is applicable. So the simple answer is "probably, but you should probably think about it" :)
Is it possible to create a static sidebar on the left-hand-side of a list view in Filemaker?
I was hoping to have editable search criteria on the left and a list on the right.
No, not in list view, although you can achieve that UI with a portal. There are a lot of ways to populate the portal based on the search criteria - you can build a complex self-join relationship, use portal filtering (which is the easiest way, but will be slow for large numbers of records), or do either a scripted find in another window (slower but easy to program) or an SQL query (faster but requires a plugin and harder to program) and populate a global field with the IDs of the matching records and do a join based on that.