I have to model the following use case:
I have record A and B related by a master-detail relationship
I need to hold on A informations from the most recent B (let's say B it's some sort of query to an expensive data source)
I need to hold on A the navigable reference to the most recent B (i.e. the one I selected as data source for A)
How can I model this? Is the only possibility to go through code / a custom VisualForce controller to make this link navigable ?
Related
We can add page relationship in two different ways using named relationships and pages data type which is kind of advanced content modelling in Kentico..
if we go through named relationships then we can give a meaningful relationship between to content node by providing description. So, we get a relationship name called “is related to”(example). When we use this in practice, then we get [page A] {is related to} [Page B].
if we go through pages data type then we assign some content on the form tab, records are created in the “CMS_Relationship” table as ad-hoc via the “RelationshipIsAdHoc” column and there is no relationship name for this as such. It is marked as Ad-hoc. and Relationship name is also added page type name underscore some randon guid example abc.product_3d628a37-7637-4a21-b0b4-e1dd1a00a3bc
My question is when we try to use page data type and we need to add relationship through api code, then how can we add because in kentico api to add page relationship through api code RelationShipNameID is mandatory field. We don't have this RelationShipNameID as we are not going through named relationship.
Found out the way
Need to retrieve ad-hoc relatioshipnameinfo object, e.g. like this:
string codeName = GetAdHocRelationshipNameCodeName("fillclassnamehere", field);
var relationshipNameInfo = GetRelationshipNameInfo(codeName);
and then use is with API:
RelationshipInfoProvider.AddRelationship(leftSiteId, rightSiteId, relationshipNameInfo.RelationshipNameId)
I have two objects - "Account" and "Appointment". I'm trying to pull the value of the field "Status" from the "Appointment" object where "Account.Initial_Date" matches "Appointment.Date_Time". I initially tried making a new field in the "Account" object to return a text field and see if maybe it would return the first value:
Appointment__c.Status__c
Which results in the error:
"Field Appointment__c does not exist. Check spelling."
I was told that it's too difficult to link from "Appointment" to "Account" because there can be multiple appointments per account, which is why I'm trying to link based on the date fields. My next attempt was using VLOOKUP, but I read that this only works between custom objects, and I think I'm working with standard objects here... what kind of solution should I be looking for?
Adding the tag apex here in case this can only be achieved via a script of some sort - if that's the case, I'll make attempt via that.
I was told that it's too difficult to link from "Appointment" to "Account" because there can be multiple appointments per account
This is incorrect. That relationship appears to be exactly the same as that between Contact and Account - one Contact, many Accounts. It's a very common relationship pattern in Salesforce.
If an Appointment is logically related to an Account, it should have a relationship field referencing the Account object to which it is related.
However, having a one-to-many relationship does not mean you can trivially represent specific data points from the many side to the one side. The native tool to do so is the Roll-Up Summary Field, but it does not apply to your use case.
There's really three ways to implement your objective, which is essentially implementing a variant of a roll-up summary. VLOOKUP(), which works only in Validation Rules, does not apply here.
Write two Apex triggers (one on Account and one on Appointment) to react to all changes that would influence what value should appear in the Account__c.Status__c field.
Write equivalent Process and Flow declarative automation, which cannot get 100% of the way there because Process Builder and Flow cannot react to delete events.
Use the free and open source Declarative Lookup Rollup Summaries application to define a roll-up summary. DLRS can populate a field from the child object (Appointment) to the parent (Account) based on a sorting by another field (Date_Time__c).
I have a system whereby you can create documents. You select the document type to create and a form is displayed. Data is then added to the form, and the document can be generated. In Laravel things are done via Models. I am creating a new Model for each document but I don't think this is the best way. An example of my database :
So at the heart of it are projects. I create a new project; I can now create documents for this project. When I select project brief from a select box, a form is displayed whereby I can input :
Project roles
Project Data
Deliverables
Budget
It's three text fields and a standard input field. If I select reporting doc from the select menu, I have to input the data for this document (which is a couple of normal inputs, a couple of text fields, and a date). Although they are both documents, they expect different data (which is why I have created a Model for each document).
The problems: As seen in the diagram, I want to allow supporting documents to be uploaded alongside a document which is generated. I have a doc_upload table for this. So a document can have one or more doc_uploads.
Going back to the MVC structure, in my DocUpload model I can't say that DocUpload belongs to both ProjectBriefDoc and ProjectReportingDoc because it can only belong to one Model. So not only am I going to create a new model for every single document, I will have to create a new Upload model for each document as well. As more documents are added, I can see this becoming a nightmare to manage.
I am after a more generic Model which can handle different types of documents. My question relates to the different types of data I need to capture for each document, and how I can fit this into my design.
I have a design that can work, but I think it is a bad idea. I am looking for advice to improve this design, taking into account that each document requires different input, and each document will need to allow for file uploads.
You don't need to have a table/Model for each document type you'll create.
A more flexible approach would be to have a project_documents table, where you'll have a project_id and some data related to it, and then a doc_uploads related to the project_documents table.
This way a project can have as many documents your business will ever need and each document can have as many files as it needs.
You could try something like that:
If you still want to keep both tables, your doc_upload table in your example can have two foreign keys and two belongsTo() Laravel Model declarations without conflicts (it's not a marriage, it's an open relationship).
Or you could use Polymorphic Relations to do the same thing, but it's an anti-pattern of Database Design (because it'll not ensure data integrity on the database level).
For a good reference about Database Design, google for "Bill Karwin" and "SQL Antipatterns".
This guy has a very good Slideshare presentation and a book written about this topic - he used to be an active SO user as well.
ok.
I have a suggestion..you don't have to have such a tight coupling on the doc_upload references. You can treat this actually as a stand alone table in your model that is not pegged to a single entity.. You can still use the ORM to CRUD your way through and manage this table..
What I would do is keep the doc_upload table and use it for all up_load references for all documents no matter what table model the document resides in and have the following fields in the doc_upload table
documenttype (which can be the object name the target document object)
documentid_fk (this is now the generic key to a single row in the appropriate document type table(s)
So given a document in a given table.. (you can derive the documenttype based on the model object) and you know the id of the document itself because you just pulled it from the db context.. should be able to pull all related documents in the doc_upload table that match those two values.
You may be able to use reflection in your model to know what Entity (doc type ) you are in.. and the key is just the key.. so you should be able.
You will still have to create a new model Entity for each flavor of project document you wish to have.. but that may not be too difficult if the rate of change is small..
You should be able to write a minimum amount of code to e pull all related uploaded documents into your app..
You may use inheritance by zero-or-one relation in data model design.
IMO having an abstract entity(table) called project-document containing shared properties of all documents, will serve you.
project-brief and project-report and other types of documents will be children of project-document table, having a zero-or-one relation. primary key of project-document will be foreign key and primary key of the children.
Now having one-to-many relation between project-document and doc-upload will solve the problem.
I also suggest adding a unique constraint {project_id, doc_type} inside project-document for cardinal check (if necessary)
As other answers are sort of alluding to, you probably don't want to have a different Model for different documents, but rather a single Model for "document" with different views on it for your different processes. Laravel seems to have a good "templating" system for implementing views:
http://laravel.com/docs/5.1/blade
http://daylerees.com/codebright-blade/
Here's a brief description of the models:
Model A represents a piece of equipment and has a name and a state
Model B represents a specific state of many model A's
Model B should relate to many model A's but only for a specific state of model A
Is it possible to model something like this in the datastore? I need the state of model A to be independent of any model B's, but when I peer into a model B I need to know what the state of the model A's should be that the model B is representing.
The current way I am achieving this is by making model B have string fields representing the different model A's with the name of the field being the name of the model A and the value of the field being the state the model A is supposed to be in.
This works, however it's completely static and requires manually adding fields into model B when the number of model A's change. I'm looking for a dynamic approach to solve this problem.
I hope this isn't too confusing, please ask for more clarification if it's needed.
You can use reference properties for this:
class A(db.Model):
state = db.ReferenceProperty(collection_name="equipment")
When you create A, you set the state property to the corresponding B entity.
This also creates a property in the B entity called equipment that can be used to get all the A entities that reference the particular B.
Suppose you have a B entity for broken equipment in a variable broken. You can get all the broken equipment this way
broken.equipment.get()
This is also available with ndb but the details are a little different and you'll need to check the docs for that.
Given the model below:
CustomerType1(id, telephone, address)
CustomerType2(id, telephone, name)
OrderType1(id, timestamp, customerType1.id, comments, enum1)
OrderType2(id, timestamp, customerType2.id, comments)
OrderType3(id, timestamp, name)
How would I model the following?
OrderList(id, OrderType.id, ..)
OrderItem(OrderList.id, MenuItem.id)
A. Would I need 3 different types of OrderLists in order to adapt to the orderTypes?
OrderList1(id, OrderType1.id, ..)
OrderItem1(OrderList1.id, MenuItem.id)
OrderList2(id, OrderType2.id, ..)
OrderItem2(OrderList2.id, MenuItem.id)
OrderList3(id, OrderType3.id, ..)
OrderItem3(OrderList3.id, MenuItem.id)
Or
B. Would 3 definitions of a relationship between orderLists and OrderTypes be better?
OrderList_Type1(orderList.id, orderType1.id)
OrderList_Type2(orderList.id, orderType2.id)
OrderList_Type3(orderList.id, orderType3.id)
This seems like a really inefficient way to store data and I just feel like i've modelled this really incorrectly (although it still makes sense, it might not be good for scaling/efficiency?). Is there a better way to model this?
Note: the given model can be changed but it would still have to contain the same information.
1. Your UML model is ok
From the point of view of UML class diagram your model and the OrderList, OrderItem extensions you want to add are clear and unambiguous and I don't see any modeling question there.
To avoid excessive copy/pastes I have only added 2 parent classes named as ...Base. It is common OOP modelling technique
Drawn as UML class diagram your model looks like this:
2. For the physical implementation I would choose B
As for the implementation "model" of this model from the two choices you gave ((A) many copy/pastes, (B) somehow normalize and minimize the schema) I would go the (B) path drawn below.
It is how one of our company's software systems models class inheritance in the relational language and it works and it works quite well.
In our system most of the necessary glue code is automatically generated. Main thing is the automatically generated OrderType2View which automatically joins corresponding field from the parent table OrderTypeBase and automatically translates all DML operations e.g. the insert as DML operations in both OrderType2 and OrderTypeBase automatically adding correct OrderTypeClassId fields to all records in the parent table. So that it is easily distinguishable which child table actually contains the specific part of the record.
Thanks to the generator we can easily extend the model with other parent classes (the inheritance hierarchy and the number of joined tables can be of any depth) and still enable some older code to treat them as their general parents - without caring about the details.
I don't know if there are better ways, given the (A) or (B) I would choose (B) because it is a design that works (I have seen it :)