In Mondrian all cubes, measures, dimensions, hierarchies, levels, properties have two identifiers: a unique name, for schema definition and a caption, displayed to the user, which may not be unique.
I am wondering if the same concept is in the distinction between id and name attributes of the dimension tag in icc-schema xml?
I did not found anything similar for hierarchy, level and properties. Correct?
Within the dimension XML definition:
"id" is used internally by icCube to link facts to dimensions.
"name" is what being displayed to the end user and is used in MDX to identify the dimension within a query.
Hierarchies and levels are used differently so there is no such needs.
Hope that helps.
Related
I am working on a web project where the user should be able to create custom types of merchandise containing any amount of properties of different types (numbers, text, etc). E.g: a box, which has name, price and physical dimensions, and a bottle, which has name, price, and volume.
What would be the best way to represent this in code and in the database?
My first idea was to create a basic template for a piece of merchandise, and dump all the custom data in a single field as stringified JSON. The downside is that this data couldn't be used for IQueryable search, filtering, sorting.
I can also think of creating a separate table, in which I'd store all the custom fields of all merchandise, and referencing them via relations. Wouldn't this, however, cause problems with scaling, as I will be essentially storing all custom properties everywhere in a single table.
Is in the best way to do it? There is no way to create new classes and database tables on the fly in .NET Core, of course, but what other options there are?
Thank you for your time,
I'm doing this in my current side project, and I've done it in the past as well. Basically, you will have a base Product table (or whatever you want to name it). Then you also have tables such as ProductAttributeType and ProductAttribute.
The base Product table would contain attributes common to all products, such as Name and Price.
ProductAttributeType
ProductAttributeTypeCode VARCHAR(10)
AttributeTypeName VARCHAR(50)
Where ProductAttributeTypeCode contains a short / abbreviated code for the attribute type (e.g. "BOOL"), and AttributeTypeName is a friendly name (e.g. "Boolean" or "Yes/No").
ProductAttribute
ProductId INT -- Foreign key to Product table
ProductAttributeTypeCode VARCHAR(10) -- Foreign key to ProductAttributeType table
AttributeName VARCHAR(100) -- The name of the product attribute (e.g. "Volume")
AttributeValue VARCHAR(MAX) -- Contains the actual value of the product attribute
Product has a one-to-many relationship with ProductAttribute.
This is the approach I've taken in the past, as well as in a current project, and it works pretty well. It appears to be a pretty common approach for solving this sort of problem. The only "downside" I can think of is that you need to make sure that the value in the ProductAttribute.AttributeValue column matches the appropriate type for ProductAttributeType(Code). If you design your code properly, and it's well thought out, it's really not so bad, in my opinion.
Can someone check my ERD, because I don't know whether I'm doing it correctly or not. I'm not sure about the difference between strong and weak entity, what I'm sure is that strong entity has their own primary key.
Other than that, is it correct i need to take Payment_ID as foreign key in my order table ? and what other attribute that i could have in my ORDER TABLE
Maybe some suggestion on what to add or improve on my ERD. Here i have a image for my ERD. Thank You
Entity Relationship Diagram
PAYMENT has an ORDER_ID and ORDER has a PAYMENT_ID. Having both fields is redundant, I would remove ORDER.PAYMENT_ID which would be a nullable field if customers don't pay immediately.
ORDER_DETAILS requires a PK, either a surrogate key ORDER_DETAIL_ID or the combination of ORDER_ID, ITEM_ID.
Can a PAYMENT use only one or more than one COUPON? The cardinality on the crow's foot line says more than one, but the PAYMENT.COUPON_ID field would allow only one. A nullable PAYMENT_ID in the COUPON table would be a better choice.
You have some doubtful minimum cardinalities. A CUSTOMER must place at least one ORDER? Ok, I can accept that. An EMPLOYEE must take at least one ORDER? So everyone in the company must take orders, and you're not going to record employees until they've taken an order? Also, every ITEM must be referenced in ORDER_DETAILS? Are you not going to want to record items on offer before they're ordered?
Finally, a note on terminology: your diagram is better called a table diagram, not an ERD. To be called an entity-relationship diagram, a diagram has to distinguish the concepts of the entity-relationship model. The style of diagram you used doesn't distinguish entity sets (i.e. ID fields) from value sets (non-ID fields) or entity relations (tables with single-field PK) from relationship relations (tables with composite PK, i.e. ORDER_DETAILS is a relationship relation).
I have a content app with a dominating unique field that I would like to use as the node name for new nodes. The problem is that it contains characters that cannot be part of a JCR node name, and thus if I were to link it to jcrName rather than a custom property it will get mutated into something that isn't useful for the fields original purpose (among others, the field value will contain slashes).
My current solution adds an additional field for the node name, and while this certainly works, it adds a UI field to the detail for no reason that is apparent to the users of the app.
Is there a way to have a field that reads and writes a string value to a custom property, yet that is also used (in its clened form) to name the node?
You could use this as a base, paying special attention to the code in 2.b.ii. (especially setNodeName), and ignoring the yaml bits.
I hope this helps!
In AX2009, how is it possible to find the table that is related to an InventTransType in the code?
For instance, InvnetTransType::Sales is related to the SalesTable, but how is it possible to get the table id or table name from SalesTable in the code?
I do not think this is possible, because there is no 1:1 relationship between the elements of the InventTransType enum and tables. At best there is a 1:n relationship (e.g. you could argue that InventTransType::Sales is related to table SalesLine just as well or even better as table SalesTable). Note also that the documentation on the enum says that it specifies "the module that generated the transaction".
It really depends on the question you ask and the data you want to retrieve. That said, here are some points you could research, maybe one of them fits your question/requirements. If all else fails, you can always write your one mapping method that takes an enum element and gives you the id of the table you think is appropriate for this element(standard AX does this in several cases to map other entities to the enum elements, see for example table InventDimSetup, method transType2FieldId).
cross references: check the cross references of the enum or of an enum element, that should give you an idea which table(s) are associated with which element
relations of table InventTrans: for some of the enum elements, you can find table relations in table InventTrans (but unfortunately not for all of them); ponus point is that by using reflection, you can analyze the relations and get the referenced table (which is probably as close to your requirement as it can get in standard AX)
I need to sort my view by a specific field that is actually a node reference field.
For some reason, however, the node reference field does not appear in the sort criteria list.
Is there any reason for that? How can I solve this problem?
You can't sort by a node because Drupal wouldn't know the criteria for sorting a node to say which is first and which is second, etc.
I assume you mean that you want to sort by some field (like the title) of a node that is referenced.
To sort by a field in the referenced node, you have to the referenced node in a relationship to join the tables. Them you can simply add a sort by 'title' field but be sure to select the correct relationship under the Relationship drop down when you create the sort field.