I want to know the significance of the OrderPart entity in moqui and what are basic differences between OrderPart and OrderItem entity?
You are correct that OrderPart and OrderItem are similar in a way, they are both detail entities to the OrderHeader master entity. For general info on master/detail and other data model patterns see:
https://moqui.org/m/docs/framework/Data+and+Resources/Data+Model+Patterns
For more specific information about the Order data model see:
https://moqui.org/m/docs/mantle/Mantle+Structure+and+UDM/Order
The use of OrderItem and OrderPart are very different, items being the line items for the order and parts being a break down of the order under OrderHeader to allow for shipping to multiple locations on the same order, or any other business requirement for splitting orders. Order Parts are used in different ways in different companies as a generic model but you can get an idea of the fields that are intended to be different for different parts of an order by looking at the fields on OrderPart vs OrderHeader.
Related
I have more experience with SQL databases than I do with Symfony and am hoping someone can clarify the association mappings on how Doctrine connects the database to Symfony.
Taking a one-to-many mapping between Category and Product as an example:
I have very little need to record productIDs as a long string in each category record and I assume that having it is an unnecessary overhead. If I really needed to get a list of all products in a category record in the future though then I assume I could just manually query it still?
By extension, to get the above, I would need a unidirectional many-to-one association. If this is the case though, then would I still (and how would I?) be able to control such things as on delete cascade if required?
I think you are not totally understanding how this works in Doctrine. I hope this helps:
If you do a one-to-many between your Category and Product (one category has many products) with doctrine then it means that all you need is a category_id column in your product table (product is in this case the owning side of the relationship). You can make the relationship bi-directional without any consequences for the category table. Doctrine will allow you to get the products for a category easily by doing:
$category->getProducts();
In the background a query will be performed where all products with matching category_id column are resolved from your database and added to the products collection in the Category entity.
Check the example in the docs. It is exactly like yours, but then a one-to-many between product and features.
To prevent all products from loading when querying your category you can mark the inverse side as fetch="EXTRA_LAZY".
If you still have questions after this, just leave a comment.
Update:
So to make it very clear: doctrine does not add a column inside the category table. In your case the products property only exist in the object model not in the database model.
I was just after some input on database design. I have two tables, Orders and Items.
The items table is going to be a list of items that can be used on multiple orders, each item has an id
The way i thought to do it at the moment, was in the order to put an array of comma seperated ids for each item in the order.
does that sound like the best way?
also im using linq to entity framework and i dont think id be able to create a relationship between the tables, but i dont think one is needed anyway is there, since the items are not unique to an order
Thanks for any advice
The way I thought to do it at the moment, was in the order to put an array of comma separated ids for each item in the order. Does that sound like the best way?
Absolutely not - It will be MUCH more difficult in SQL to determine which orders contain a particular item, enumerate the items (to get a total, for example), and to add/remove items from an order.
A much better way would be to create an OrderItem table, which has a foreign key back to Order and Item and any other attributes relating to the item in that order - quantity, discount, comments, etc.
As far as EF goes, it will probably create a third entity (OrderItem) that will "link" the two tables. If you don't add any extra properties (which you probably should) then EF will probably create it as a many-to-many relationship between the Order and Item entities.
As far as I have understood from your question (it is not very clear), every Order can have multiple Items and every Item can be used in multiple orders. If this is what you want, you have a many to many relationship, that must be resolved using an intersection entity. This intersection entity has 2 foreign keys, one for item and one for order. Using it, you can identify what items are in a certain order and what orders need a certain item.
As my explanation is very short and very sloppy, I will recommend you the following references:
http://sd271.k12.id.us/lchs/faculty/bkeylon/Oracle/database_design/section5/dd_s05_l03.pdf
Resolve many to many relationship
Also, you proposed design is very bad, as it breaks the first normal form: no attribute can have multiple values. You shoud try to build databases at least in third normal form.
Regarding the database design, you would usually create a third table - ORDER_ITEMS - linking the two tables, containing columns (foreign keys) for order id and item id. You might also want to include a column for quantity.
I need some advice on modeling an ecommerce domain.
The client sells two products:
Custom art work, the design specified by the customer.
Prints of art with a message on the back specified by the customer.
Here is my cut down database model so far.
Products:
Id
Description
Price
Orderlines:
Id
OrderId
ProductId
Attributes:
Id
Name
OrderAttributes:
AttributeId
OrderlineId
Value
The products table will have the 2 products from above.
The order line links the selected product to an order.
The attributes holds the custom field names for each product.
For example the custom artwork product would have the attribute design.
The order attributes links the ordered product to it's customs attributes and has the value.
For example custom artwork product, with an attribute of design, with a value of paint a house.
I would also like to map this database model to code as well using nhibernate.
Is there a better way of modeling this data?
A couple of suggestions:
The Orderlines table should contain the price (and possibly the description) of the product so that item prices can change without affecting existing orders. Similarly, the Orders table (not shown) should contain customer information (e.g. shipping address) that may change. The data that makes up an order can't change and the easiest approach is to flatten and denormalize it.
The OrderAttributes structure is called an entity-attribute-value model and it has many drawbacks. In general I recommend avoiding it and adding the needed columns to the Orderlines table. If needed, your application can subclass Product and OrderLine so that a CustomArtWorkProduct creates a CustomArtWorkOrderLine when it's added to an order.
In an object-oriented program relations are expressed as associations.
That is:
If Product has Orders then Product must have a collection of Orders.
If an Order is for a Product, the Order must have a property Product.
and so on.
In object-oriented programming you don't associate by an identifier: you don't need this because this is a different world ruled by hierarchical data.
Honestly, if you follow what I said before, NHibernate will be a very powerful tool as it'll be able of loading objects and properties without your intervention.
Think about "getting all orders of some product": you're not going to intentionally execute an SQL Join but you're going to access to the Orders property of Product and NHibernate will translate this access to the database world.
This is the point of using an OR/M. It's not just "I map tables as is". It's about joining two very different worlds: the object-oriented hierarchical world with relational data with no pain.
Check this very old (2004!) CodeProject article and how it creates the Northwind SQL Server database-based model:
http://www.codeproject.com/Articles/8773/NHibernate-in-real-world-applications
Don't pay attention to how maps the model to the database but to the model design.
Check this article, it's more modern than the other one:
http://litemedia.info/introduction-to-nhibernate
I am having issues with translating my ER diagram into tables. In a ternary relationship with weak entities, according to the requirements:
A supplier supplies certain number parts for a project
A project uses the parts from the different suppliers.
The same kind partsfrom different suppliers are used by different
projects.
There is a name for a supplier and the city where the supplier
locates.
There is a name, color, and weight for a part.
Do I create a fourth table for supplies containing: projectNO, supplierName, City, Partname, color and weight? 6 attributes that makes up the PK for that table?
I don't think your relationship between Project and Supplies is right. Similarly, your relationships between Supplies and each of Supplier and Part are all backwards.
The crow's foot goes at the many end of the relationship. Supplies should be the ternary relationship table that you're talking about. If you are using natural keys then all of the key columns from Project, Supplier and Part should appear in Supplies as both FK to their respective tables and all together as PK.
However, your natural keys look like things that could change (e.g. supplier moves cities, part changes colour or weight). I think you might want to consider using surrogate keys to avoid future update anomalies.
I'm trying to model the domain of my system but I've come across and issue and could do with some help.
My issue is one of perspective. I'm modeling a system where I have a Customer entity which will have a number of Order entities and the system will be required to list all the Orders for a selected Customer (perspective 1). I therefore modeled a Customer class which contains a collection of Orders... simple. However I've just realised that the system will also need to list all Orders with the details of the Customer (perspective 2) which would mean that I had a single Customer reference from each Order.
The problem is that from each perspective I will be taking time to create object which I will not be interested in E.g. When I will display a list of Orders a Customer instance will be created for each order; in turn the Customer instance will then hold a collection of Orders they have made (which from this perspective I'm not interested in!!).
Could anybody help with suggestions? I've come across this issue before but I've never taken the time to design a proper solution.
Regards,
JLove
I have seen this before. The trick is to differentiate between Customer-Identity and Customer-Details (e.g. Orders). You can then link from all Order-Objects to the Customer-Identity-Object, and in the other view link from the Customer-Identity-Object to the Customer-Details-Object which further links to Order-Objects (you probably want this ordered chronologically).
The implementation can be held as on Object-System or as a relational Database (in which case you would have a table "Customers" with CustomerID as Key, their addresses etc; and a table "Orders" with OrderID as key, and CustomerID as another column.