What's the best way to handle this scenario?
I have a customer Model(Table) contains contact info for customers
I have Prospect Model(Table) contains contact info for store visitors that aren't customers
I have an Opportunity Model (Table) when either a customer or Prospect visits the store.
In my view I want to generate a new oppportunity. An opportunity can only contain either 1 customer association or 1 prospect association but not both.
In my opportunity model I currently have both the customer and prospect as nullable foreign Id's and and navigation properties. I also have an ICollection<> for Customers and Prospects on the opportunity model.
Is this the right way to do handle a conditional association?
When it comes to the view, I'm stuck on how would I make the customer or prospect association?
I am a computer science student, and this is my understanding on DB relationships:
Since you have two types of "People" - Customer - and Prospect - you could potentially have a table called "Person". In the Person table any common data among both entities would be stored (FirstName, LastName, Address1, Address2, City, State, Zip, etc...).
To indicate that a Person is a Prospect, you would have a Prospect table, which would have a PersonId to link to the person table. You can store more specific attributes about a prospect in this table.
The same would go for a Customer - you would have a Customer table - that would have a PersonId column to link to the Person table, and any specific attributes for the Customer entity.
Now you have a database in which you can derive other entities ... say an Employee entity > you have your base Person Entity to start from. And your Employee table would link back to it, and also have other custom columns for employee specific data.
Does that make sense?
Or maybe I'm going about this all wrong :). Please correct me if I am wrong as I am still a student.
I think you are stuck because you now have two fields on an "Opportunity" record (Customer OR Prospect), one of which MUST be null. With the model I proposed, your Opportunity would link to a Person, in which you can define custom business rules restricting say... an Employee Opportunity (which actually might not be a bad idea).
For the referenced Person in your Opportunity model, it would not be an ICollection (since you specifically said that an opportunity can have ONLY one person). It would simply be a single class such as:
private virtual Person Person { get; set; }
EDIT: If you don't want to restructure your entire database, you could just have a dropdown that asks what type of Opportunity this is (Customer, or Prospect). Based on the selection, you would add a foreign key in your Opportunity table to link to your [Customer or Prospect].
Related
I have these models:
Partner
Invoice
Bill
Transaction
CreditNote
Invoice, Bill, Transaction, and CreditNote belong to Partner.
and Partner has many invoices, bills, transactions, credit_notes.
I want to make SOA reports, which are based on date.
for example:
DATE TYPE ITEM
2021-1-1 partner invoiced us invoice_number..
2021-1-2 us invoiced partner bill_number..
2021-1-3 partner paid us transaction_debit
2021-1-4 us paid partner transaction_credit
2021-1-5 partner paid us credit_note
I use `rappasoft livewire data table to show this information.
I get partner stuff like this:
Partner::where('id', 1)->with('invoices', 'bills', 'transactions', 'credit_notes')->get()
I don't know how to display these information in a table a sort based on date
How to do this?
It sounds to me like your structure is wrong. All of the five things that you're putting in your table are what I'd consider "transactions" (not to be confused with your model "Transactions".
That being the case, then you want either want a Transactions model which is morphable (that's the more complicated solution) or which has a "type" property.
If morphable, each transaction would then be associated to the corresponding partner, and to the corresponding model - invoice, bill, payment, refund, etc. - on a "morphsTo" basis.
If you went down the easier route, each transaction would just have a type, linked to a TransactionType model, which would indicate the type of the transaction.
As things stand, your structure is overcomplicated. Either of the above approaches would simplify it.
I have two entities:
Person
Employee
Person hasOne Employee. Employee belongsTo Person.
Generally speaking, my task is: when person data changes, I need to make a copy of the model in revisions table. Each Person also hasMany PersonRevision. Kind of log of updating persons, which is used in many places in our application.
Technically, I separated Person and Employee, because not every person is employee and employee has a lot of additional columns.
So, the question is: when I update Person and do not touch its attributes but update the employee (which belongs to the person) attributes, the Update event does not fire in PersonObserver.
And that's true since Person attributes has not been changed.
But
I consider Employee as a part of Person, separated one to one in order to keep persons (which are not employees) table clean
Every time person attributes or its employee attributes updated I need to create 2 revisions: person & employee. For this purpose I want to use Event Observers
So, how can I do this?
The quickest way for you in this situation is to create a listener for employee.updated event and trigger person.updated event inside it. So each time an Employee is updated, it automatically triggers Person update. You can then go further and check which fields are updated, and if those are only fields related to Employee and none related to Person, then NOT trigger the person.update event.
Here's a small Laravel model events tutorial in case you need some guidelines.
I'm in need of some advice on something I haven't run across before, and while it is a necessary component of a friend's project, I am willing to be flexible in how I should go about it.
In their little museum, they have a staffing and document problem. For several sets of donor types, there are a variety of donor document requirements and what I am trying to do is have the donor type on the donor class reference to many on another table which lays out the required documents of that donor type and what type of required they are (either optional, but recommended or straight up required).
At the moment these are my donor model fields:
id
lastName
firstName
donorType
docStatus
And the relationship to the donorRequiredDocs model is:
public function donorRequiredDocs(){
return $this->hasMany('App\donorRequiredDocs', 'donorTypeID', 'donorType');
}
My donorRequiredDocs table is setup as such:
id
donorTypeID
requireType (optional, required)
docType (letter, agreement, etc - but in an INT which references another table)
Now say I have this example:
I am a donor, and my donorType is 1, and 1's are required to have the following documents:
Agreement
Letter of Approval
Notary Required SEM
and are recommended but not required to have:
Photograph of Donation
Statement of Account
And I go to donate an object to the museum, after they select my name and record for the new donation which would use my donor table id to pull up the model information they have on me. I want the the donation record docStatus to remain NULL or 0 until at the very least, the donation record has a relationship with one of each of the three above document types before it can be set to 1.
In this case the donation model is setup as such:
- id
- title
- donorID
public function documents(){
return $this->hasMany('App\donationAttachment', 'donation_id', 'id');
}
And the donationAttachment model is setup as such:
id
title
docType (which uses the same numbering system as the donorRequiredDocs table field reference)
donation_id
created_at
updated_at
In the end, besides automatically changing the status once the project determines that the donation has at least one of each of the required documents, I'd like to print it out on the blade until all requirements have been met.
If there is something I missed, I'm happy to post it, I'm just not sure about how to go about this and would appreciate any and all help. Thanks in advance.
I have a table customers with the fields id, name and so on.
One table doctors with the fields id, name.
Then there is one table subject_areas which has all subject areas which a doctor can have. The fields are id, text.
So, each doctor can have multiple subject areas. There is one pivot table doctor_subject which is a belongsToMany relation.
Here is my problem: A customer can have multiple doctors, but only for a specific subject area. I tried it with a new table customer_doctor with the fields id, customer_id and doctor_subject_id. But how do i map this in Eloquent?
Issue was in relation between tables. After chat clarification this came out as solution:
Html form is written in a way that customer first choose doctor, then depending on selection choose several of his available areas.
In that scenario customer needn't to be related to areas directly and should be related to areas only over relation with doctor.
Also as side note, if needed deeper relations, models on pivot tables could be created and used as well.
SQL Server 2012 MVC3 EF4.3.1 Code First project.
I have a Teacher and Student table with a one to many relationship. The Teacher’s tables Id will be used as the account number so its Id numbering needs to be separate from the Student’s. I would like to create a Person table (containing shared properties such as First, Last, Phone, Email) to reduce redundancy on the properties. Person will also have a one to many relationship to an Address table.
I’ve thought of trying a Table per Hierarchy model with Teacher and Student inheriting from Person but then the Id sets would not be separate and I would have to have a one to many relationship internally on the Person table. I could generate the ID’s through code but is an internal one to many doable or practical?
Another scenario would be to setup Person as a child table with a one to one between and Teacher and Person and a one to one between Student and Person but I’m not sure how or if it’s possible to have two separate one to one’s on a table.
Is there a practical way to do what I want or should I not worry about the redundancy and not use a Person table? If I went that route would it be possible to have two separate one to many relationships to an Address table (Teacher-Address and Student-Address)? Or for that matter a one to many (Teacher-Address, teacher may have an additional shipping address) and one to one (Student-Address)?
Thank you
Another way to do it is to have a one to one between a Person and a Role table. Teacher and Student are merely roles in this arrangement. A given Role can be fulfilled by many Person instances.
You could also do a Person table with an IsTeacher flag.
I can see two possibilities:
One: Go with your Student and Teacher inheriting from a base table of Person and not worry about the 'redundancy'. It's not a redundancy because your relating a Student and a Teacher not a Person to a Person and so in your database and DOM the Person table and Person class know nothing of the Teacher to Student relationship, it only knows that its a person. The teacher and student relationships are stored in there respective types, not the person type. Also, look at Table per Type instead of Table per Heiarchy. It's much cleaner and crisper looking in the database and you don't get all the information of each type in the heiarchy in one table.
Two: Create a table that specifically holds information that both Students and Teachers share and have that related to both the Student and Teacher table separately. You could call it something like "ContactInformation".
Being a teacher and being a student are roles of people, not types of people.
You should have a table for People, a table TeachCourse to say that a Person is the teacher of a course (which in some cases are multiple teachers), a table AssistCourse to say which persons are attending a class as a student. You might have people that teach a course and assist another course, and that wasn't properly modeled in your first version.
You can also create a ContactInformation or ShippingInformation table for People to specify all their data (Some people may have multiple phones, or emails to).