I am trying to use inheritance for sake of re-usability and I have a base class named 'Partner' and two sub classes 'Lawyer' and 'Accountant' as below:
abstract class Partner{
}
class Lawyer extends Partner{
}
class Accountant extends Partner{
}
It's all good with the code, but I was wondering more when it comes to database, how do I store these information in db, should I have one table partners for both entities, or I should have separate tables for each entity, based on fact that these two differs from each other based on their attributes.
If I keep it in separated tables, and I have another table 'cases' which is related to partner:
cases: case_id, subject, description,partner_id.... My question is, how do I inner join entities based on user logged in, let say if he is laywer join lawyer table or vice versa, what if I keep adding more entities in future?
How would I do it in such a way that eventhou in future I add more Entities my db queries will not have to be changed again and again.
I can't say I favor the idea of combining lawyers and acct's into one table partners. My suggestion is to keep your db entities separate. So you will have three tables (lawyer, accountant, and cases) and cases will contain foreign keys from lawyer and accountant. Your inner joins will be simple in this case. You'll have two 1:1 relationships whereas using a partner table it will have to be 1:M relationship to get both the lawyer and the accountant - each being its own record within the Partners table. Plus don't forget all the useless NULLS you'll have since lawyers and accountants have their own specific attributes..eew!
Since you are going to use Lawyers and Accountants in the same context, I think it makes sense to use the same table.
You can simply create a partners table with the common properties, and create separate accountants and lawyers tables with a 1:1 relationship. This basically means these two tables don't get their own auto-incrementing primary key, but just a partner_id that is primary and refers to the id in the partner table.
Related
Heya I am novice web dev or actually I am still in education.
I got this situation Where I have 3 tables lets say : Students, Groups and a join table Student_group.
I put my data from Students in the student model and from groups I put its data in the Group Model so I can use it my application. But I store a date in the Student_group table because I need to know when a student changed from a group.
So my question is in which model do I put this date? Do i need to make a new model for the combined tables or do I need to add another attribute to the student model?
Thanks in advance ;D
That depends. Will the student be in many groups, or one?
If one (one to one relationship), you can decide where to put it. The column could be in either the Student table, or the Student_group. In this case, though, it may be advisable to flatten the data and simply add group columns in your Student table. You decide that as well - if it seems unnecessary to have a join for a one to one relationship (usually it is, not always), then flatten it. In either case, the data should stay in its respective model. That said, you should use the Student model if you handle it in the Student table.
If many (one to many relationship), I'd advise putting it in the Student_group table and leaving it in that model as well.
All in all, the model should be a direct reflection of the data it's representing. You could make some methods inside your Student model to make it easier to get the date, for example. However, I'd personally handle that date inside of the proper model, Student_group. As mentioned, the model should be a direct representation of the data. Again, though, there's nothing wrong with making things a bit easier by creating some methods that help out the developer.
I have a general question about how to implement the best practice of model structure for an application I'm building in Laravel 5.
So, at the moment I have things set up like this:
'user' model and table: id, email, password, admin level - this is really just the info for authenticating login.
'user-details' model and table: id, userID (foreign key for user table id field), name, address etc - all the other details
'lesson-type' model and table: id, teacherID (foreign key for user-details table id field), lesson-label etc - info about different types of lessons
At the moment I have a Teacher Controller in which I'm passing through to the view:
- The info from the User table
- The info from the User-details table
- A list of different lesson types for the teacher from the Lesson-type table
But I kind of feel that all this should be tied together with one separate Teacher model which would extend the User-details model (and probably which in turn should extend the User model), but wouldn't have it's own table associated with it, but all the info pertaining to either updates for the User-details or the Lesson-types table would be stored in those relevant tables. Would this be correct?
(I should also say that users may alternatively be parents rather than teachers, and so would I would have a separate Parents model for all the properties and so on associated with parents)
I would then pass only the Teacher model object into the view and thus gain access to all the teacher info such as personal details and array of lesson types.
As I'm typing, this is sounding more and more to me like the right way to go, but it would be great to get some advice.
1 - technical implementation: I guess in the Teacher model, I'd populate all the relevant teacher into class variables (Name, array of lessons etc) in the constructor?
2 - am I over complicating this structure by having both Users AND Users details tables?
3 - Does what I'm proposing make the most structural sense in Laravel?
4 - just another thought I've just had, should the teacherID in the lesson-type table actually refer to the User table rather than the User-detail table... so user-detail and lesson-type would both be direct children of the user table??
Very much obliged for any help :)
You shouldn't extend models like that unless there is a clear inheritance. From a logical standpoint, it just doesn't make any sense since you'll have to overwrite most of what is on the User model anyway. And what you don't overwrite will be incorrectly mapped to the database because they are 2 completely different tables. What you actually want to do is utilize Eloquent relationships.
For clarity, I am assuming this basic structure:
users - id
teachers - id, user_id
user_details - id, user_id
lesson_types - id, teacher_id
Those should be 4 completely different models all interconnected using the Model::belongsTo() method. So the Teacher model would be
class Teacher extends Model {
public $table = 'teachers';
public function user() {
return $this->belongsTo('App\User');
}
}
When you query for a teacher, you can do Teacher::with('user')->get(). That will return all records from the teachers table and on each instance of the Teacher model, you'll be able to call $teacher->user and get the User instance associated with that teacher. That is a full model, not just extra data, so you have access to everything on the User Model, which is generally the main reason for extending
For your list of questions:
I may be misunderstanding you, but this isn't how an ORM works. I'd suggest going back and reading through the Eloquent docs (if you're running 5.0, I suggest reading 5.1's docs since they are much, much better)
It will depend on who you ask, but I tend to think so. If the data is clearly related and there is no reason for it to be shared across record types (for example, I generally have an addresses table that all records reference instead of having 5 address fields repeated on multiple tables), I believe it should all be on one table. It just makes it more difficult to manage later on if you have it in separate tables.
There will be those who disagree and think that smaller scopes for each table are better and it will likely allow for quicker queries on extremely large datasets, but I don't think it's worth the extra trouble in the end
No, as I have explained above
The teacher_id column should reference the teachers table, assuming that lessons belong to teachers and cannot belong to just any user in the system. Using the ORM, you'll be able to do $lesson->teacher->user->userDetails to get that data
I really think you need to go back and read through the Eloquent docs. Your understanding of how Eloquent works and how it is meant to be used seems very basic and you are missing much of the finer details.
Basics
Relationships
Laracasts - Laravel Fundamentals - You would benefit from watching Lesses 7-9, 11, 14, and 21
I am making an e-commerce web application. The following are the things that I have planned.
products table to contain only few columns viz. id, name, code, SKU_no.
meta_information_products table containing columns viz. id, product_id [foreign key to products table], meta_title, meta_keywords, meta_description.
measurement_product table containing columns viz. id, product_id, width, height, weight, length
And similarly other tables in relation to products.
So my questions are:
Shall I create different Model for each of the points above and
then create the One-To-One relationship with products and
related table ? Or shall I create only one Model called Product and declare all the fields in just one table product.
If I create different models for Product, what should be the name of the method to be declared for creating the One-To-One relationship, and same with Product Model.
For example, consider the following: I have created two models called Product and MetaInformationProduct and I have created relationship with both the tables. Now how do I name the method for the following:
class Product extends Model {
...
public function methodName() {
$this->belongsTo('App\Product');
}
...
}
And for MetaInformationProduct:
class MetaInformationProduct extends Model {
...
public function methodName() {
$this->hasOne('App\Product');
}
...
}
I guess Stack Overflow is not the best place to ask questions of this kind, since your questions do not necessarily have right or wrong answers. There are multiple possible ways to go about constructing your app's data structure, and ultimately it all boils down to one's personal style of coding. So almost every developer would have an original 'right answer' to your questions.
Here's what I think. Why do you need three separate tables for all that data? As far as I can see, all three tables contain data related one-to-one to a single product. That means more complicated models and relations in development, and more resources and longer execution time in production. You could avoid all that if you create one products table with the following columns: id, code, SKU_no, name, title, description, width, height, length, weight. That will simplify your models significantly and reduce the number of queries trifold.
Additionally, I think I can spot a piece of bad practice in your table structure. In your current meta_information_products table you have a column named meta_keywords. I'm guessing that that field would contain multiple keywords of a product. This negates the benefit of relational database structure and will give you headaches down the road. Instead, I would create one products table as I described in the previous paragraph, then another table titled keywords, with the following columns: id, keyword. Lastly, you'd need a relational table titled keyword_product with the following columns: id, keyword_id, product_id. This gives you the ability for one product to have multiple keywords, and for one keyword to be assigned to multiple products. It's a well known 'Many to many' relation, and you can read more about it in the Laravel's official documentation.
In general, you should create one model for one database table, except for the relational tables. So in case you do as I would, you would then need two models: Product and Keyword. For its content, it's best that you refer to the link in the previous paragraph.
I would like to implement the classes that I made into database,
I have a class like
Class Person {
firstname ;
lastname;
email
etc
}
Class Teacher extends Person {
salary;
graduatedFrom ;
etc ...
hasMany: [classess, experiences] ;
}
Class Student extends Person{
tuitionFee ;
parentName ;
etc ...
}
I am going to use mysql database for this project,
Should I create one table named Person and store all information there
or should I create different table for each class (like Teacher, Student, etc) ?
note: i am going to implement this using YII Framework and MYSQL database.
You would be better of creating Two tables one that stores all the person details, this table would have a foreign key which references to other table which would store the role details (eg teacher, Students)
This way would be advisable with respect to scalability as well, i.e. for example tomorrow if your application has 50 roles, you wont need to create 50 tables, you just would need to add a entry in the role table.
table person would be something like this (firstname, lastname, email, role_id,etc)
role_id here is the primary key of role table
role table would be something like this (role_id,role_name,role_desc,etc)
I would create only one table Person with a column which will act as an identifier as to what the Person is (a Student, a Teacher etc...).
Advantage: we do not have to pay attention to sql joins while retrieving information as it would be fetching information from just one table! It will also give benefit when saving data. Think you do not have to save information to two different tables while storing data for Student.
In case, if you create separate table for each class ( and want to avoid sql joins) then you may end up creating lot of duplicate information in your database.
Less the number of the tables will produce a clean code.
Given the above case, it would still make sense, if you create a separate table for a special entity which you think should be stored separately (with a reference key to the main table) and do not want to clutter up the original table.
You can use a couple of different design patterns for this:
Class Table Inheritance
Concrete Table Inheritance
For more information on this (and other useful patterns) read Martin Fowler's Patterns of Enterprise Application Architecture.
For other examples:
Practical Object Oriented Models In SQL
In a StackOverflow clone, what relationship should a Comments table have to Questions and Answers?
Storing inherited objects in a database
I am trying to model a database for my current project and I came across a new problem. I have a Project which is supervised by Supervisor, Coordinator and Company. So Project table has Supervisor.id as foreign key and so on. There is also Student table which contains Project.is as a foreign key (because many users can do a project). This is how it is right now. What I would like to do is to have a User table containing a column named type which allows me to see what the role of that particular user is (also student). Even though the table will contain many NULL entries, I will have far less redundant code.
However, the main reason I want to have one User table is that I am using CakePHP and it is not easy to have different models log in. Is this possible in a nice way?
Thanks
EDIT: Maybe I should say that every one of these roles will have different permissions.
I see three tables: USER, GROUP, and ROLE.
Users would be assigned to groups, and groups given roles. I think you need three, not one.
And cardinality matters: I can see where a USER could be assigned to many GROUPS; a GROUP could have many USERS; a ROLE could be assigned to several GROUPS; and a GROUP could have many ROLES. There are many to many JOIN tables as well:
USER <-> USER_GROUP <-> GROUP <-> GROUP_ROLE <-> ROLE
This is normalized - nothing is repeated this way. USER, GROUP, and ROLE have primary keys. The JOIN table primary key is a composite of the two IDs in each row.
It depend on how you will use your associations.
Why not
For example: if you use relation to output data later and you sure, that you database scheme will not changed, than ... why not? your main targets: quality of code and speed of development, so, not matter how much columns with null you will have.
But
if you not sure in your requirements or plan to extend database scheme you can use two columns
supervisor_model
supervisor_id
which will store apropriate values: Company, 77 (I mean that 77 it's id of come Company )
Another approach
You can UUID for you supervisor_id so, it will be unique among several tables and you have not many NULL and extra columns.