React-admin enterprise edition provides a module called ra-relationships. This gives the ability to deal with many-to-many relationships in the interface. I'm building an app with users and roles as separate resources (i.e. a user can have multiple roles and vice-versa).
From what I can see, the ra-relationships module relies on the premise that your primary keys in all tables (user, roles and user_roles) are simply named "id". However, this particular app has the primary keys as user_id, role_id and user_role_id.
Has anyone come across a method whereas the module can work with this kind of set up?
Related
Consider the scenario between a Project, Task, and a User (ER diagram attached included):
A project can have multiple tasks and a task can be in multiple projects (thus the many-many relationship ProjectTask)
A project can have multiple users and a user can be in multiple projects (thus the many-many relationship ProjectUser)
Check the above example's ER Diagram here
Now a ProjectTask can be assigned to multiple ProjectUsers and a ProjectUser can be assigned multiple ProjectTasks, basically a TasksAssigned relationship
How will I go about storing that information in a database? Can two relationships have a relationship? If yes, is there a better way to showcase this scenario? And if no, how do you show this relationship?
You can have a three-way relationship, in your case:
user
project
task
You probably want to guarantee that the user and task have the same project. That can be handled by declaring composite foreign keys to the projectTasks and projectUsers tables. The structure guarantees that the user and task are in the same project (because it is explicitly mentioned in the row in this table).
I am working on creating an application with multiple parent accounts each of which has different multiple users. Each account consists of a set of data of similar type but needs t be maintained separately. eg. inventory of each organization which their respective users can view.
What is the best practice:
1: Create different database tables for each organization
2: Create a common table and have an extra column for the organization it belongs to.
As mentioned, do a one table for organization, one for equipment, one for persons and so on. It is step 1 - separate table for separate entity.
After that connect them with relationships: primary key in main entity to foreign key in sub entity. Other words every row in equipment table would have column with id of organization it belongs to. And so on.
There are many other circumstances, including subdividing entities to such called normal forms, you can study it if it needed, to reduce data consistency supply costs. But it could also negatively affect performance.
Anyway: same class entities commonly should be stored in one table.
The best practice in OLTP (transaction processing) is to create a common table and to implement a subtyping in some way, for example "have extra tables with columns for the organization subtype". In OLAP (analytical processing) warehousing it is still a good practice but the mapping of subtypes can be implemented differently. In OLAP datamarts the solution "one table per organization" can be a good practice.
You may have a look on the book "Programming with databases" which covers these topics: subtype/subclass mapping, OLTP vs OLAP, denormalization etc.
I'm porting a MySQL database to Core Data for a Mac OS app. I have two many to many tables in my database. In addition to containing the foreign keys, there are a few data columns. Is it possible to add attributes to a many to many relationship in Core Data? It doesn't look like it to me. My fallback is to replicate the linkage table in Core Data. Are there any problems doing this?
An example:
A record has one or more artists performing on it.
An artist performs on zero or more records.
The linkage table row contains a foreign key for the record, a foreign key for the artist, the instruments the player performed with, and a notes column that adds additional information such has which track the artist performed on.
You are correct: relationships themselves cannot have attributes. And you are on the right track in modelling the linking table as an intermediate entity. This approach is alluded to in the CoreData Programming Guide section on "Modelling a relationship based on its semantics". In their case, they model a (reflexive) many-many relationship from Person to Person using an intermediate FriendsInfo entity with a ranking attribute.
In your example, you might have a Record entity, an Artist entity, and an intermediate Appearance entity. The Appearance entity would have attributes for Instruments and Notes, and (to-one) relationships to Record and Artist (each with a to-many inverse).
The slight downside is that you have to create the Appearance object in order to link a Record object and an Artist object, rather than just adding them to the relevant relationship. You will also have to watch for uniqueness of the combination of Record/Artist, if that's important to you: by default there could be many Appearances for the same Record and Artist.
This question extends the example Eloquent : Working With Pivot Tables provided in the Laravel Documentation.
The relationship here is that a User has many Role objects that it can relate to, and each Role is made up of a number of Task's.
The relationships between these models are:
User and Role:
Each Role may only relate to one User, however a User may have many Role's
A one-to-many relationship
Role and Task
Each Role can have many Task's associated with it, and each Task can belong to several Roles
A many-to-many relationship
In terms of a database schema (MySql), we therefore have:
A users table that has no foreign keys
A roles table with a user_id foreign key
A tasks table
A role-task pivot table
In plain English, the constraint I need to apply is that a user can not be associated with multiple roles that are made up of exactly the same tasks, however two role's can be made up of exactly the same task's
Is there an in-built way to apply this constraint using Laravels Eloquent ORM system? If not, what would be a tidy workaround?
edit:
Eloquent-like description:
User hasMany Role
Role belongsToMany Task
Question: How to prevent assigning to a user multiple roles having exactly the same related collection of tasks
I am designing a product that is mainly to be used by small organizations. The idea is for every member of the organization to have their own accounts (known as subaccounts). At the same time, there needs to be data that can be accessed by anyone with that organization. I am trying to decide between two courses of action.
Separate Table for Organizations
In this design, there would be a organizations table and a users table. The users would be connected to organizations via foreign key, and the shared data would use the foreign id of the organization.
User Conglomerate
Here an additional field in the users table would point to another row in the table (the parent) that represents the primary account for the organization and is linked to all the shared data.
Which approach would be superior in this situation?
Both approaches seem reasonable and workable, but I would lean towards having a separate table for organizations as ultimately the idea of an 'organization' is different to that of an 'user'. You may need to have different attributes for an organization than you would a user (e.g. you may need to have more than one 'superuser' for an organization at some stage), and so having this data in a separate table would make it (a) easier to code against (b) more extensible and future-proof (c) more efficient and normalized in storage.