I'm using the nosql Azure Cosmos DB (Core SQL) with EF Core Cosmos 3.1.
I have a structure of packages and modules where :
TypeCar has 0...N TypeUser
TypeUser has 0...N TypeCar
I need to list TypeCars and TypeUsers, even if they have no children.
How shoud I structure my models ?
Should I store only list of IDS ? Duplicate objects in children ? Both ?
For most of your reads:
If you need parent object and all or most children (All properties) then you should duplicate.
If you need parent object but occasionally need one or more children, then store a list of child IDs in the parent.
If you need parent object and all or most children (few properties) then you should store a list of child IDs plus the few child properties you need in the parent.
Your writes will also impact the option you choose.
More info can be found here:
https://learn.microsoft.com/en-us/azure/cosmos-db/modeling-data
Related
I've set up a Core Data mirroring to CloudKit using NSPersistentCloudKitContainer. My simplified data structure consists of List and Item. List have one-to-many relationship items with many Items, Item has parentList property.
When I am getting CKRecord associated with List NSManagedObject and sharing it, I expect all child Items to be shared too. I know, I can set parentRecord property for each CKRecord associated with the List
childRecord.setParent(parentRecord)
But I believe there is some smart way to avoid doing that manually, because everything is mirroring automatically and it looks stupid to start handling each single property manually to only set parentRecord.
Is there any way to do that for NSManagedObjects? Because my custom relationship does not mean for CloudKit that the List is parent for the Item.
I am working on a POC (to move part of functionality from relational DB to cloud datastore). I have few questions:
I would need to refresh few "kind" every night as the data comes up
from a different data source (via flat files). I read about it, and
understood that there is not TRUNCATE kind of functionality in
datastore. I believe, only option is to retrieve the keys from the
"kind" in a loop and delete entity by entity. And use import functionality to load the new set of data. Is there any better
option?
Assume I have a kind called department, and a kind called
store. Now, I need a kind called dept-store. So for this parent
nodes are department and store. Is there a way to enforce this kind
of relationship? From the documentation I see that there can only be
one parent.
If i have a child entity in kind1 whose parent is
present in kind2, and they are linked together, is there a way to
query all the properties present in kind1 and kind2 together? From
relational DB perspective, it is like equi-join with "SELECT *". I
am looking for an equivalent functionality in datastore.
In order to answer your questions:
There is two ways to delete multiple entities. First, you can use Cloud Dataflow to delete entities in Bulk [1]. Second, once keys are retrieved you can make a batch delete operation by passing the keys to Datastore delete function, you have the usage example here [2]. In order to retrieve the keys you can run keys-only query [3].
In Datastore an entitiy can have only one parent but can have multiple children. But for your use case you may try to have a third kind, dept-store, and assign its properties as the keys of the entities from the department and the store kinds. This solution might need a good understanding of your neeeds for implementation, as Datastore by nature is Non-relational database.
You can lookup multiple entities providing the keys retrieved from kind1 and kind2 with batch operations [2].
I'm trying to get my head around NoSQL and Google Cloud Datastore, and I don't know how to chose between two different options for storing data.
I have a list of orders, and every order is for an unspecified number of products. What are the pros/cons of storing the product list as an array property for the order entity vs having product child entities for each order parent?
Firstly, be well aware of the distinction between the 2 possible approaches of implementing a relationship between entities:
one entity can contain a Key type property pointing to another entity (which might or might not exist!) - this is a functional relationship only, not one at the datastore level
having the 2 datastore entities in a parent-child (ancestry) relationship, inside the same datastore entity group.
Using the 2nd one has scalability implications, see also:
Ancestor relation in datastore
E-commerce Product Categories in Google App Engine (Python)
As for storing a list as an array property vs as separate entities, see Creating your own activity logging in GAE/P (where repeated properties is just how array properties are called in the ndb client library context).
I am designing a database for storing products and some properties belonging to them. The properties can be inherited from parent product to the child product. For example:
ProductA ---> PropertyA, PropertyB
|-ProductB ---> PropertyC
In this example, ProductB should have PropertyA and PropertyB in addition to PropertyC. In order to get all the properties of a certain product, I need to go through all the parents and accumulate all the properties in a list. However, the Property class itself is a database entity, so can I use it to define normal objects (i.e. detached from database) without having them affecting the database contents, i.e. create, modify, delete instance as normal C# objects?
Yes you can. Entity Framework 4.0 onwards supports what is known as a POCO entity (Plain Old CLR Object). They can exist entirely separately from your database concerns and when appropriate you can attach them to an instance of an Entity Framework Context for persistence to the database.
Likewise you can Detach entities from a Context having retrieved them from the database through the same Context should you choose to manipulate them within your Domain Model in such a way that you don't want them persisted again.
Depending on whether you're doing true Code First or Database First will determine the development workflow you use for creating these entities.
I am currently using LINQ and the Entity Framework to do my database connection layer. In my database I have a Files table and a Products table. I also have a ProductHasFiles table that joins the 2 in a many to many relationship.
My issue is this. I have a single file loaded in my context and I have a list of Product IDs that I need to either attach or detach from to the file record. How do I do that?
I know I can get all of the current Products attached to the File by doing File.Product.Load(); but how do I detach them once I do this? Also, is there a way to attach existing Products without loading the whole Product entry? I already have the ID so I hope that would be enough.
If you want to add or remove object without retrieving it, use stub entities: How to delete an object without retrieving it. Create stub, add to context, add to file.Products.
Why do you want to detach after loading?