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?













0















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?










share|improve this question
























  • With proper indexes joins are no performance problems. Without them, joins are expensive.

    – jarlh
    Mar 8 at 9:44















0















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?










share|improve this question
























  • With proper indexes joins are no performance problems. Without them, joins are expensive.

    – jarlh
    Mar 8 at 9:44













0












0








0








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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

















  • 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












2 Answers
2






active

oldest

votes


















2














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)
);





share|improve this answer






























    1














    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.






    share|improve this answer




















    • 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










    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
    );



    );













    draft saved

    draft discarded


















    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









    2














    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)
    );





    share|improve this answer



























      2














      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)
      );





      share|improve this answer

























        2












        2








        2







        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)
        );





        share|improve this answer













        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)
        );






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 8 at 9:54









        a_horse_with_no_namea_horse_with_no_name

        305k46467562




        305k46467562























            1














            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.






            share|improve this answer




















            • 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














            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.






            share|improve this answer




















            • 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








            1







            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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












            • 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

















            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Can't initialize raids on a new ASUS Prime B360M-A motherboard2019 Community Moderator ElectionSimilar to RAID config yet more like mirroring solution?Can't get motherboard serial numberWhy does the BIOS entry point start with a WBINVD instruction?UEFI performance Asus Maximus V Extreme

            Identity Server 4 is not redirecting to Angular app after login2019 Community Moderator ElectionIdentity Server 4 and dockerIdentityserver implicit flow unauthorized_clientIdentityServer Hybrid Flow - Access Token is null after user successful loginIdentity Server to MVC client : Page Redirect After loginLogin with Steam OpenId(oidc-client-js)Identity Server 4+.NET Core 2.0 + IdentityIdentityServer4 post-login redirect not working in Edge browserCall to IdentityServer4 generates System.NullReferenceException: Object reference not set to an instance of an objectIdentityServer4 without HTTPS not workingHow to get Authorization code from identity server without login form

            2005 Ahvaz unrest Contents Background Causes Casualties Aftermath See also References Navigation menue"At Least 10 Are Killed by Bombs in Iran""Iran"Archived"Arab-Iranians in Iran to make April 15 'Day of Fury'"State of Mind, State of Order: Reactions to Ethnic Unrest in the Islamic Republic of Iran.10.1111/j.1754-9469.2008.00028.x"Iran hangs Arab separatists"Iran Overview from ArchivedConstitution of the Islamic Republic of Iran"Tehran puzzled by forged 'riots' letter""Iran and its minorities: Down in the second class""Iran: Handling Of Ahvaz Unrest Could End With Televised Confessions""Bombings Rock Iran Ahead of Election""Five die in Iran ethnic clashes""Iran: Need for restraint as anniversary of unrest in Khuzestan approaches"Archived"Iranian Sunni protesters killed in clashes with security forces"Archived