Do i really need individual table for my three types of users?How can you represent inheritance in a database?How do you effectively model inheritance in a database?Best database design for a discussion system with varying category types?Two tables or one table?database design suggestion neededTable design for user's information as well as login credentials?Database Architecture regarding User Accounts and Account DeletionDatabase design with types and subtypesStar schema and bridge tables for many to 1/2 relationshipKeeping one table or multiple table for similar type of data which one is best while considering high performanceDatabase design for multi-level user type and profilesSQL many tables with same column(s) - export to separate table and JOIN on each query?
Print name if parameter passed to function
If you attempt to grapple an opponent that you are hidden from, do they roll at disadvantage?
Can somebody explain Brexit in a few child-proof sentences?
Is there a problem with hiding "forgot password" until it's needed?
Bash method for viewing beginning and end of file
Lay out the Carpet
What will be the benefits of Brexit?
Is there any reason not to eat food that's been dropped on the surface of the moon?
Short story about space worker geeks who zone out by 'listening' to radiation from stars
Can I use my Chinese passport to enter China after I acquired another citizenship?
How was Earth single-handedly capable of creating 3 of the 4 gods of chaos?
Failed to fetch jessie backports repository
How could Frankenstein get the parts for his _second_ creature?
How can I use the arrow sign in my bash prompt?
Can a monster with multiattack use this ability if they are missing a limb?
What are the ramifications of creating a homebrew world without an Astral Plane?
Ways to speed up user implemented RK4
Do there exist finite commutative rings with identity that are not Bézout rings?
Was Spock the First Vulcan in Starfleet?
Should my PhD thesis be submitted under my legal name?
Generic lambda vs generic function give different behaviour
How can I replace every global instance of "x[2]" with "x_2"
Hide Select Output from T-SQL
Will it be accepted, if there is no ''Main Character" stereotype?
Do i really need individual table for my three types of users?
How can you represent inheritance in a database?How do you effectively model inheritance in a database?Best database design for a discussion system with varying category types?Two tables or one table?database design suggestion neededTable design for user's information as well as login credentials?Database Architecture regarding User Accounts and Account DeletionDatabase design with types and subtypesStar schema and bridge tables for many to 1/2 relationshipKeeping one table or multiple table for similar type of data which one is best while considering high performanceDatabase design for multi-level user type and profilesSQL many tables with same column(s) - export to separate table and JOIN on each query?
If i have three type of users. Let's say seller, consumers, and sales persons. Should i make individual table for there details like name, email passwords and all other credentials etc with a role_type table or separate table for each of them. Which is the best approach for a large project considering all engineering principles for DBMS like normalization etc.
Also tell me Does it effect the performance of the app if i have lots of joins in tables to perform certain operations?
postgresql database-design
add a comment |
If i have three type of users. Let's say seller, consumers, and sales persons. Should i make individual table for there details like name, email passwords and all other credentials etc with a role_type table or separate table for each of them. Which is the best approach for a large project considering all engineering principles for DBMS like normalization etc.
Also tell me Does it effect the performance of the app if i have lots of joins in tables to perform certain operations?
postgresql database-design
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44
add a comment |
If i have three type of users. Let's say seller, consumers, and sales persons. Should i make individual table for there details like name, email passwords and all other credentials etc with a role_type table or separate table for each of them. Which is the best approach for a large project considering all engineering principles for DBMS like normalization etc.
Also tell me Does it effect the performance of the app if i have lots of joins in tables to perform certain operations?
postgresql database-design
If i have three type of users. Let's say seller, consumers, and sales persons. Should i make individual table for there details like name, email passwords and all other credentials etc with a role_type table or separate table for each of them. Which is the best approach for a large project considering all engineering principles for DBMS like normalization etc.
Also tell me Does it effect the performance of the app if i have lots of joins in tables to perform certain operations?
postgresql database-design
postgresql database-design
edited Mar 8 at 9:50
a_horse_with_no_name
305k46467562
305k46467562
asked Mar 8 at 9:42
Deepak TyagiDeepak Tyagi
237
237
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44
add a comment |
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44
add a comment |
2 Answers
2
active
oldest
votes
If the only thing that distinguishes those people is the role but all details are the same, then I would definitely go for a single table.
The question is however, can a single person have more than one role? If that is never the case, then add a role_type
column to the person table. Depending on how fixed those roles are maybe use a lookup table and a foreign key, e.g.:
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
role_id integer not null references role_type
);
However, in my experience the restriction to exactly one role per person usually doesn't hold, so you would need a many-to-many relation ship
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
);
create table person_role
(
person_id integer not null references person,
role_id integer not null references role_type,
primary key (person_id, role_id)
);
add a comment |
It sounds like this is a case of trying to model inheritance in your relational database. Complex topic, discussed here and here.
It sounds like your "seller, consumer, sales person" will need lots of different attributes and relationships. A seller typically belongs to a department, has targets, is linked to sales. A consumer has purchase history, maybe a credit limit, etc.
If that's the case,I'd suggest "class table inheritance" might be the right solution.
That might look something like this.
create table user_account
(id int not null,
username varchar not null,
password varchar not null
....);
create table buyer
(id int not null,
user_account_id int not null(fk),
credit_limit float not null,
....);
create table seller
(id int not null,
user_account_id int not null(fk),
sales_target float,
....);
To answer your other question - relational databases are optimized for joining tables. Decades of research and development have gone into this area, and a well-designed database (with indexes on the columns you're joining on) will show no noticeable performance impact due to joins. From practical experience, queries with hundreds of millions of records and ten or more joins run very fast on modern hardware.
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55060480%2fdo-i-really-need-individual-table-for-my-three-types-of-users%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If the only thing that distinguishes those people is the role but all details are the same, then I would definitely go for a single table.
The question is however, can a single person have more than one role? If that is never the case, then add a role_type
column to the person table. Depending on how fixed those roles are maybe use a lookup table and a foreign key, e.g.:
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
role_id integer not null references role_type
);
However, in my experience the restriction to exactly one role per person usually doesn't hold, so you would need a many-to-many relation ship
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
);
create table person_role
(
person_id integer not null references person,
role_id integer not null references role_type,
primary key (person_id, role_id)
);
add a comment |
If the only thing that distinguishes those people is the role but all details are the same, then I would definitely go for a single table.
The question is however, can a single person have more than one role? If that is never the case, then add a role_type
column to the person table. Depending on how fixed those roles are maybe use a lookup table and a foreign key, e.g.:
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
role_id integer not null references role_type
);
However, in my experience the restriction to exactly one role per person usually doesn't hold, so you would need a many-to-many relation ship
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
);
create table person_role
(
person_id integer not null references person,
role_id integer not null references role_type,
primary key (person_id, role_id)
);
add a comment |
If the only thing that distinguishes those people is the role but all details are the same, then I would definitely go for a single table.
The question is however, can a single person have more than one role? If that is never the case, then add a role_type
column to the person table. Depending on how fixed those roles are maybe use a lookup table and a foreign key, e.g.:
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
role_id integer not null references role_type
);
However, in my experience the restriction to exactly one role per person usually doesn't hold, so you would need a many-to-many relation ship
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
);
create table person_role
(
person_id integer not null references person,
role_id integer not null references role_type,
primary key (person_id, role_id)
);
If the only thing that distinguishes those people is the role but all details are the same, then I would definitely go for a single table.
The question is however, can a single person have more than one role? If that is never the case, then add a role_type
column to the person table. Depending on how fixed those roles are maybe use a lookup table and a foreign key, e.g.:
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
role_id integer not null references role_type
);
However, in my experience the restriction to exactly one role per person usually doesn't hold, so you would need a many-to-many relation ship
create table role_type
(
id integer primary key,
name varchar(20) not null unique
);
create table person
(
id integer primary key,
.... other attributes ...,
);
create table person_role
(
person_id integer not null references person,
role_id integer not null references role_type,
primary key (person_id, role_id)
);
answered Mar 8 at 9:54
a_horse_with_no_namea_horse_with_no_name
305k46467562
305k46467562
add a comment |
add a comment |
It sounds like this is a case of trying to model inheritance in your relational database. Complex topic, discussed here and here.
It sounds like your "seller, consumer, sales person" will need lots of different attributes and relationships. A seller typically belongs to a department, has targets, is linked to sales. A consumer has purchase history, maybe a credit limit, etc.
If that's the case,I'd suggest "class table inheritance" might be the right solution.
That might look something like this.
create table user_account
(id int not null,
username varchar not null,
password varchar not null
....);
create table buyer
(id int not null,
user_account_id int not null(fk),
credit_limit float not null,
....);
create table seller
(id int not null,
user_account_id int not null(fk),
sales_target float,
....);
To answer your other question - relational databases are optimized for joining tables. Decades of research and development have gone into this area, and a well-designed database (with indexes on the columns you're joining on) will show no noticeable performance impact due to joins. From practical experience, queries with hundreds of millions of records and ten or more joins run very fast on modern hardware.
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
add a comment |
It sounds like this is a case of trying to model inheritance in your relational database. Complex topic, discussed here and here.
It sounds like your "seller, consumer, sales person" will need lots of different attributes and relationships. A seller typically belongs to a department, has targets, is linked to sales. A consumer has purchase history, maybe a credit limit, etc.
If that's the case,I'd suggest "class table inheritance" might be the right solution.
That might look something like this.
create table user_account
(id int not null,
username varchar not null,
password varchar not null
....);
create table buyer
(id int not null,
user_account_id int not null(fk),
credit_limit float not null,
....);
create table seller
(id int not null,
user_account_id int not null(fk),
sales_target float,
....);
To answer your other question - relational databases are optimized for joining tables. Decades of research and development have gone into this area, and a well-designed database (with indexes on the columns you're joining on) will show no noticeable performance impact due to joins. From practical experience, queries with hundreds of millions of records and ten or more joins run very fast on modern hardware.
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
add a comment |
It sounds like this is a case of trying to model inheritance in your relational database. Complex topic, discussed here and here.
It sounds like your "seller, consumer, sales person" will need lots of different attributes and relationships. A seller typically belongs to a department, has targets, is linked to sales. A consumer has purchase history, maybe a credit limit, etc.
If that's the case,I'd suggest "class table inheritance" might be the right solution.
That might look something like this.
create table user_account
(id int not null,
username varchar not null,
password varchar not null
....);
create table buyer
(id int not null,
user_account_id int not null(fk),
credit_limit float not null,
....);
create table seller
(id int not null,
user_account_id int not null(fk),
sales_target float,
....);
To answer your other question - relational databases are optimized for joining tables. Decades of research and development have gone into this area, and a well-designed database (with indexes on the columns you're joining on) will show no noticeable performance impact due to joins. From practical experience, queries with hundreds of millions of records and ten or more joins run very fast on modern hardware.
It sounds like this is a case of trying to model inheritance in your relational database. Complex topic, discussed here and here.
It sounds like your "seller, consumer, sales person" will need lots of different attributes and relationships. A seller typically belongs to a department, has targets, is linked to sales. A consumer has purchase history, maybe a credit limit, etc.
If that's the case,I'd suggest "class table inheritance" might be the right solution.
That might look something like this.
create table user_account
(id int not null,
username varchar not null,
password varchar not null
....);
create table buyer
(id int not null,
user_account_id int not null(fk),
credit_limit float not null,
....);
create table seller
(id int not null,
user_account_id int not null(fk),
sales_target float,
....);
To answer your other question - relational databases are optimized for joining tables. Decades of research and development have gone into this area, and a well-designed database (with indexes on the columns you're joining on) will show no noticeable performance impact due to joins. From practical experience, queries with hundreds of millions of records and ten or more joins run very fast on modern hardware.
edited Mar 8 at 12:18
answered Mar 8 at 10:45
Neville KuytNeville Kuyt
22.9k2641
22.9k2641
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
add a comment |
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
1
1
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
Good point (that's why I added the "but all details are the same" to my answer). In addition to those links: Postgres supports real table inheritance (although it has some serious drawbacks with regards to foreign keys)
– a_horse_with_no_name
Mar 8 at 10:49
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
@Neville Kuyt See i have 19 entries for seller and 28 entries for consumer and these 19 entries are also in these28 so which approach should i follow?
– Deepak Tyagi
Mar 8 at 11:16
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
Are you saying that a seller can also be a consumer?
– Neville Kuyt
Mar 8 at 11:34
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
No i want a login table for both of them and seller have additional details then consumer.
– Deepak Tyagi
Mar 8 at 11:57
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55060480%2fdo-i-really-need-individual-table-for-my-three-types-of-users%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
With proper indexes joins are no performance problems. Without them, joins are expensive.
– jarlh
Mar 8 at 9:44