We are designing a multi-tenant system and we want to employ The shared database, Schema sharing, shared data table.
Since Our Tenants could be State (US States), County or Individual Organizations. The following figure depicts a high level view. (Where O1,O2.. are Organizations, and U1,U2.. are users)
A state can have many organizations under it.
An Organization will one or more User under it.
An Organization can have one or more Organizations (sub organization) under it.
A User from one organization cannot belong to other organization.
Every Tenant will have its own Admin who can perform CRUD on Organization/User (Ex Creating Organization and assigning User to Organizations)
A SuperAdmin (from our Company) will be able to activate/deactivate any Tenant.
Below is a high level ER diagram. Since tables are shared between tenants, we have a tenant_id column in all tables.
Since an organizations can be nested under an organization, I am thinking of having a self referencing table with Discriminator Column.
I am looking for inputs to optimize/correct this ER Diagram and before anyone starts yelling at the ER, I would like to mention that I am a programmer and not a DB expert :).
Related
I have a simple and probably. banal question. I am working on the first, conceptual phase of an entity-relationship diagram.
This DABMS will be used by some Managers, that will control (registrate and modify accounts) of customers.
In my diagram I have the two entities "MANAGER" and "CUSTOMER". Is it necessary to connect them with a relationship (M:N), to specify that the Managers are those who will manage the customers' account, or this relationship is unnecessary?
to specify that the Managers are those who will manage the customers
No. ER diagrams typically show relations that are reflected in your database.
Example, what would be visible in your ERD
Each customer has a manager assigned who's responsible for this customer => 1:n - each customer has one manager but one manager can be responsible for multible customers.
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 designing the database schema for a CRM. It has the following tables: users, organizations, contacts, addresses, organization_types.
organizations might be a company, a non-profit or a individual.
users have a many to many relationship with organizations. The reason is because one company, for example, can have a salesman and a manager on the app with two different logins. On the other hand, there is the possibility that a salesman is doing sales for two different companies.
contact and addresses have a one to one relationship with organizations. My client only want a organization to have one of each of those.
I designed it in a way that a organization can also be a client, that would belong to another organization. That would mean that the organization table had a one to many relationship with itself.
That made sense to me because they seem to be the same entity. A client will also need a contacts and addresses table and it could also be a company, non-profit or individual.
The point to consider that another developer raised is that with time, it would be expensive to query the database to differentiate organizations that are our clients from the ones that are clients from our clients.
What is the best approach? Would it be better the make a client_organizations table and separate those two?
I will keep one table and create a column named parent_organization. Parent_organization will be nullable and store primary key of parent organization that child organizations belong to
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.
Hi I'm drawing an ER Diagram using MySQL Workbench for my final year project. It's about a shipping company, where buyer & shipping agent are involved in a shipping process with my client.
So far the buyer and agent have same attributes. So I decided to keep both of their data in a table and differentiate them using an attribute (type in my case).
As you see in my picture I couldn't able to make a N:M relationship between shipping table and external table. It always give me 1:M relationship. When I try to do the relationships manually it creates a another relational table and make a 1:M relation with it.
Can anyone assist me with my problem? Further how efficient to have a relational table in my case.