Have you ever been building any app that handled client’s data, was it e-commerce, crm or anything similar, you surely wondered, how to store it in the database.
Most of the time we consider client as Organization or Person, one or the other. Obviously the two are completely different entities in real life, so it wouldn’t be wise to treat them the same. However, speaking of business, we want to treat both entities like a client, no matter if it’s a company or an individual.
So the problem arises, how to design the database efficiently while not having to do checks here and there within our code, to pick what entity we are dealing with this time.
And here comes the Party Model
– if not familiar with, feel free to google it, there are many discussions already.
For this tutorial I’m going to introduce party model as simple as possible, by the Eloquent models and tables for simple e-commerce site.
Let’s start with the Person, that is every invidual, who can become our client:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// app/models/Person.php class Person extends Eloquent { // Tell Eloquent what table we use for this model. // Laravel will look for 'people' table by default so we could skip it protected $table = 'people'; // Keep it really simple protected $fillable = ['firstName','lastName']; } |
migration:
10 11 12 13 14 15 16 17 18 19 20 |
* * @return void */ public function up() { Schema::create('people', function(Blueprint $table) { $table->increments('id'); $table->string('firstName', 255); $table->string('lastName', 255); $table->timestamps(); }); |
Now the organization model:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// app/models/Organization.php class Organization extends Eloquent { protected $table = 'organizations'; // formal stuff appropriate for your country // vatin = tax identification number protected $fillable = ['name','vatin']; } |
10 11 12 13 14 15 16 17 18 19 20 |
* Run the migrations. * * @return void */ public function up() { Schema::create('organizations', function(Blueprint $table) { $table->increments('id'); $table->string('name', 255); $table->string('vatin', 255)->unique()->nullable(); $table->timestamps(); |
You may wonder where all the important data is, right? That’s because now we will introduce Party model where we store all the fields that are common to both Person and Organization.
Again, for sake of this tutorial I will keep the things simple, so let’s agree that we store single address, email and phone per client.
What that mean is, that I won’t create separate tables for the above.
Now, party will be a wrapper for both Person and Orgnization. We will not access these models directly, instead we will call Party model.
With Eloquent this is going to be trivial task. I will setup polymorphic relationship between Party and Organization / Person models. In brief I’m telling Eloquent that Organization and Person is able to be ‘cast’ to Party, thus both will be partyable.
So Here’s the Party model and table:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
// app/models/Party.php class Party extends Eloquent { protected $table = 'parties'; protected $fillable = ['symbol','phone','email','address','zip','city']; // polymorphic relation public function partyable() { return $this->morphTo(); } } |
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
* Run the migrations. * * @return void */ public function up() { Schema::create('parties', function(Blueprint $table) { $table->increments('id'); $table->string('symbol', 20)->unique(); $table->string('phone', 255); $table->string('email', 255); $table->string('address', 255); $table->string('zip', 255); $table->string('city', 255); $table->timestamps(); // polymorphic magic // it will setup fields partyable_id and partyable_type $table->morphs('partyable'); $table->unique(['partyable_id','partyable_type']); |
Now we only need to update Organization and Person models with the relation:
1 2 3 4 5 6 7 |
// the same goes to Organization.php and Person.php public function party() { return $this->morphOne('Party','partyable'); } |
And this is it, we have setup relations and prepared the ground for real work.
In the next part we will be loading and storing the data through our Party Model, and I’ll show you how easy it is again with Eloquent!