I'm trying Google Cloud Datastore, but I have some doubts. I know that the ideal is to use a relational database for make a shop online, but I would like to try using Google Cloud Datastore.
How would a database of 2 tables be made? Stock and Products. The stock table has 2 columns (ref and units) and the product table has 3 columns (name, ref and price).
How would you do to get all the products that have stock?... like a join, I know that we do not have joins, that's why my doubt.
There has to be an efficient way to get the stock related to the products.
There are no tables in the Datastore, you have just entities with properties. And, depending on the client library you use, you might have entity models.
The Stock entities can have a Key property pointing to the corresponding Product entities. You query for the Stock entities, from the results you obtain the Product keys with which you pull the respective entities.
Or, if they're always in a 1:1 relationship I could use the exact same entity IDs for the corresponding Stock and Product entities, so I can make a Stock query and from the Stock entities in the result (or rather from their keys/IDs as I'd probably make keys_only queries) I can immediately compute the Product keys and get the respective entities (see re-using an entity's ID for other entities of different kinds - sane idea?).
But, in general, you might want to reconsider the general SQL approach of querying data to generate a report when you need it (and expecting that to be fast) and instead make the habit of performing the necessary computations ahead of time - whenever the data used in those computations changes. This is a much more scalable approach which works hand in hand with the datastore (and I guess with nosql in general). And for which you do not need to perform equivalent to SQL-style join ops. Basically raise the stock empty flag for a product right when you decrement its stock value, when you already know the product in question, so that you don't have to query for it later. While there also add it to the report (so that you'll have it ready when needed) and maybe trigger the restocking activity as well.
Related
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
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've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.
I want to get the union of data from different entities. I have a number of entities (different kinds of tags e.g. location, events etc) and I want data for a table view that shows "All Tags" (i.e. the union of all tag entities). How do I make a fetch request with Core Data for this kind of a use case?
I know that Core Data is not an ORM but if my explanation above was not good enough, I will explain the corresponding database use case. I have different tables e.g. events, locations, people etc and I would like to UNION the results from these different tables. Remember that a UNION concatenates the rows and not columns.
One obvious solution is to get the data from the different entities separately and then just concatenate together the NSMutableArrays. I am wondering if there is a more efficient way.
There is no way to fetch more then one entity type in a fetch request ...
UNLESS, the entities you like to 'Union' have the same base class in your model (other than NSManagedObject).
So if all your entities were to inherit from a base class named Tag for example, you would be able to fetch all of them together.
This however, will create a unified table for all these entities (a very sparse table if the intersection between the classes is small) in the actual database file.
In your case this might not be feasible as there is no real connection between 'Person' and 'Location' for instance, or you might decide that this will cause a performance issue.
The other solution will be (as you suggested) to create a fetch request for each entity.
I am trying to do something fairly easy to understand with WCF data services, but can't find how to do it.
I have 3 table, Customer, Product and a joint table Customer_Product linking the two other tables (a basic n to n relationship):
Customer <= Customer_Product => Product
I want to get a customer and its products in the same query, so I would like to do something like:
/Service.svc/Customers(23)?$expand=Products
But it tells me that there is no Products navigation property on the table Customer.
The only option that I found is to do:
/Service.svc/Customers(23)?$expand=Customer_Product
and then make another call to get the Product details.
Is there a clean way to do this?
Thanks a lot in advance.
The many to many relationships are usually modeled by the service by hiding the join table (if the only thing it stores is the relationship and there's no data in it). If you're using EF in the service this should be pretty easy to do.
If you do need to expose the join table for some reason, then you can issue a query like:
/Service.svc/Customers(23)?$expand=Customer_Product/Product
(expands can be multiple levels deep). Of course reading the results will be a bit more complicated because of the two levels there, but you do get the data you need.