I'm having trouble figuring out a data model for my project. I'm using Parse as the backend.
I intend to have users who are in groups, and the groups have text posts. What should be classes, and what should be rows in those classes.
I'm guessing a good way to do this would be, have a group, user, and post class.
The columns for the group class would be: GroupID, GroupName, postID, UserID
The columns for the user class would be: UserID, GroupsUserBelongsTo, user name, password, email
The columns for the post class would be: UserIDPostBelongsTo, GroupID, TextFile, TimeCreated
Is there anything I'm missing, or I should change.
You're thinking is a very SQL / rows based way and you shouldn't, this isn't SQL, it's objects and relationships.
So, your classes are fine, and the actual data is fine, but where you're using ids you should be using relationships. Post should just have a pointer to user. Perhaps, don't bother with a relationship from user to groups (you can query that using the other relationship), though you can, particularly if you will have lots of users / groups.
You may also want to consider roles to provide security for the groups.
Related
I am working on a multi-country application where I have different db schemas for each country. I want to understand how can i call a different query file based on the country a user belongs to.. One way i thought of was maintaining different query files for different countries (IqueryConstantsIndia, IQueryConstntChina etc) and to check the country of the user in the constructor of the repository class and then call the query file based on the same but how do i return a class name is what i am stuck with.. Can anyone help on this or if you think there is a better way of implementing this.
I have a Laravel 8 application and am wondering how to solve the problem of how to solve a typical polymorphic issue. I have an Employee model. That Employee can be an ExecutiveEmployee or EntryLevelEmployee. There will be methods an ExecutiveEmployee has that an EntryLevelEmployee doesn't have and the inverse is also true.
Using Laravel 8, is it right to create a base Employee model (without a corresponding table?) and then create two models named ExecutiveEmployee and EntryLevelEmployee that inherit from Employee? This would also imply that both employee types will have two different database tables, even though there will be a lot of overlapping data.
Does it make sense to just have one Employee model and create a migration that has the employee type listed in the model? I am assuming that it's ok if an EntryLevelEmployee has some database attributes which are relevant to it that may or may not be relevant to an ExecutiveEmployee type here, or is that an incorrect assumption?
What's the correct way to model this in Laravel 8? I prefer to keep everything in one table because of how similar the models are. I do have to keep in mind that there will be data that one has that the other doesn't. There will be different accessor methods as well.
Is it possible to have everything in one employees table while utilizing multiple models? Meaning, if I create two models named ExecutiveEmployee and EntryLevelEmployee they would both query the underlying table employees?
UPDATE 1
The more I research, the more I think polymorphism is the incorrect approach here and what I might need is Single-Table Inheritance. This package seems to bring the capability to Eloquent. Would there be a good reason to not use this?
I would use polymorphic relationships in this case, because you are more flexible and have less coupling.
Using the Single Table Inheritance (STI), you can add type specific columns in the employees table and make them nullable. But think about adding/removing types in the future.
executive_employees
id - integer
executive_specific - string
entry_level_employees
id - integer
entry_level_specific - string
employees
id - integer
name - string
email - string
employable_id - integer
employable_type - string
As for the STI the same would be
employees
id - integer
name - string
email - string
type - string
executive_specific - nullable string
entry_level_specific - nullable string
So STI would be suitable when you don't have type specific columns. But you want to add specific behavior in your code. For example a User type (Admin, Author).
Even so, it's a matter of preferences.
It really depends on the state and behavior of your employee object.
Below are few points I will consider to make a decision
If your objects' states/properties are different then definitely you will create different models as your data will be stored in different tables.
If most states/properties are same and some are different, you can
consider storing all in one table/model and for the difference in
behavior create separate table like Ron Van Der Heijden has
suggested and you can consider query scope with that to make
transaction with database.
And another view will be
How many JOINs you will create if you will create different tables,
will that impact the performance and other stuffs, will it make your
code complex?
Can you make simpler relations and handle stuffs independently?
When you are making an API, will your
code make the api overworking? or you need to create too many request
for any operation?
These stuffs will decide how you will make a decision.
Update 1:
Another point I would like to add about the package you are thinking to use, consider using a parent key in table and you can define relationships in a single model.I do not think you need to use a package, you can define it yourself, I guess.
I don't understand why you don't create a simple one-to-many relation. Based on the information you provided, the polymorphic relation looks unnecessary. I think the right way is to create employee_roles table and relations. Then you can give different permissions to different employee types. There are several ways to do that. You can create a middleware to create route restrictions. You can check the role before executing a function in the controller, and run only if the employee has permission. You can use if-else in blade not to render the parts that can't be used by auth user etc.
If you have different “types” of employees, and each employee type should have different logic then yeah, that sounds like a polymorphic relationship.
I'm making a system (using Spring + JPA with MySQL) that shows the best applicants for a certain job offer. The company and the applicants have their respective user account, and with that, they can fill in their personal/company information and their job profile/job offer conditions. With that, the system should match the job conditions (like 3+ years of experience in C) with the applicant's job profile.
My problem is that the User Account is created first, and should be independent, but these two different entities (Applicant and Company), with different attributes, are using it. So if I do something like create an applicant and company in the User Account, one of them will be always null.
How can I solve this? I guess the problem would be something like: how to implement a user account that can hold data from different entities that have different attributes (therefore, can't be grouped)? (In fact, I need one more entity, but I tried to simplify it to illustrate the problem more clearly).
I think, you should make marker interface, like public interface UserAccountable or smth. Implement this interface in your Applicant and Company classes. Then you can make a field in UserAccount class, like private UserAccountable someUser; and throught setters and getters you can assign and get this variable to Applicant or Company.
Hope this helps!
I found what I needed here: https://thoughts-on-java.org/complete-guide-inheritance-strategies-jpa-hibernate/
The problem was the mapping, not the class design per se. I could create interfaces and abstract classes to solve it in the Java world, but in the SQL world that's not possible, so the mapping is the key. In this case, I was looking for the Joined table mapping, but I realized I needed it just to not have null fields in my UserAccount, because I don't need a polymorphic query (e.g. give me the names of every 'user type' (Person, Company)), and it would be too costly performance wise to implement it that way, so I'll trade off space for performance, and I'll just reference all three user types in the User Account, leaving two of those three fields null forever.
PS: Single table mapping won't help because I do need to use not null conditions.
I have 2 different JSON Files. One with user details and other with order details. Order details table has a column user_id to match the user ordered for. I have to create a dynamo db table that has the order details nested inside the user details and insert the values from the Json files into this table using a spring-boot app. Can someone help me with this ? Do we have any example code ?
DynamoDB is NOT a relational DB so you can't have relations per se.
However, you have two ways (at least those come to my mind) to achieve what you want.
1) Have two tables: User and Order, the latter with userId field. When you load Order, get your userId and load also a User by the index id.
2) In your User.java you can have field List<Order> orders. Then you need to create Order.java and annotate this class with #DynamoDBDocument. This enables you to have custom objects in your #DynamoDBTable classes. Do not also forget about getters and setters since they are required.
I have 2 models, one called Employee and another one User,
Employee has one field pointing to User, one to one relationship.
My problem is that i need one query method to find the Employee that has the user with certain id. I need to find the Employee with certain User id.
I know the default query methods: .findOne, .findAll, but i need to create one, alright? how i can do that? i searched a lot but probably i am missing something. I didn't found how to do a query like that.
Thanks