Relationship Design - php

Question

I'm building an app where clients can create a document from a pre-defined template, edit some fields with their own text and save it. I've sketched out the relations as I think they would be, and it's mostly fine to convert into Laravel:
The only question I have is how I'd handle the FieldValue relationship. The idea is that the Template defines all the fields, then rather than re-create these on each Document, it should just look to its Template for them. That would mean the FieldValue needs to look up to its Document, to the Template of that and find the corresponding Field from there.
Is there a clean way to implement this, or is there a better way of designing the relationship to make it more practical to implement?

Answer 1

Going by your diagram, looks like a pivot table with pivot data...
Which would generally be modeled like this in Laravel:
class Document extends Model
{
public function template()
{
return $this->belongsTo('App\Template');
}
public function fields()
{
return $this->belongsToMany('App\Field')->withPivot('value');
}
}
class Template extends Model
{
public function organisation()
{
return $this->belongsTo('App\Organisation');
}
public function documents()
{
return $this->hasMany('App\Document');
}
public function fields()
{
return $this->hasManyThrough('App\Field', 'App\Section');
}
public function sections()
{
return $this->hasMany('App\Section');
}
}
class Section extends Model
{
public function fields()
{
return $this->hasMany('App\Document')->withPivot('value');
}
public function template()
{
return $this->belongsTo('App\Template');
}
}
class Field extends Model
{
public function documents()
{
return $this->belongsToMany('App\Document')->withPivot('value');
}
public function section()
{
return $this->belongsTo('App\Section');
}
}
class Organisation extends Model
{
public function documents()
{
return $this->hasManyThrough('App\Document', 'App\Template');
}
public function templates()
{
return $this->hasMany('App\Template');
}
}
With related tables (if sticking with laravel defaults):
fields
id - integer
section_id - integer
documents
id - integer
template_id - integer
templates
id - integer
organisation_id - integer
sections
id - integer
template_id - integer
organisations
id - integer
document_field
id - integer
document_id - integer
field_id - integer
value - string
Then you can access things many different ways. Here is one example:
$user = App\User::find(3);
$organisation = $user->organisation;
foreach ($organisation->documents as $document)
{
foreach ($document->fields as $field)
{
echo $field->pivot->value;
}
}
And inserting:
$field = App\Field::find(2);
$document = App\Document::find(4);
$value = 'My field value';
$document->fields()->save($field, ['value' => $value]);
Relevant docs:
Many-to-many relationships
Querying relationships
Inserting related models
Working with pivot tables

Answer 2

Hope this is what you meant:
$doc = Document::findOrFail(Input::get('docId'));
$sections = $doc->template->sections;
$fieldValues = $doc->field values;
Now you simply run on the field values and get the field and the section and start placing stuff.
For better performance I would eager load the fieldValue parameters with:
->with('field');

Answer 3

To give a answer to you're first question:
I suggest that you call it content. You can handle the content as you're doing now. The relationship as is is good enough. You've to do that separated from the other tables.
Second question: a better way
I've created a ERD myself based on you're ERD:
I've changed a few thinks.
Not so important but a document is from a user.
Templates can have sub templates. The consequence of this is that you can reuse sub templates. E.g. if you've a logo you can just place that in you're document every time.
Due to the new template table you don't need sections anymore. With the new approach you can define sub sections/templates.
Properties are all put into one table. With this approach you can define infinite properties for fields. This can be allot more flexible. These are referenced to a field and the content. The content_id however isn't needed. I've just placed it there so you can easily check which field it applies to.
The main point of you're question was the FieldValue/Content. The content is referenced to the document. From the document you can fill in the fields of the template.
I hope this is clear for you. The advantages I see are:
More flexible in properties
Content lookup is easy and referenced to a field
I haven't changed anything on the content table. Just leave it as is. It's good that way! Hope this helps you. If you use Schema designer you can retrieve you're models very easily!