Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. members db or table?

members db or table?

Scheduled Pinned Locked Moved Database
databasequestionmysqlsecuritytutorial
7 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Jassim Rahma
    wrote on last edited by
    #1

    I have multiple websites and i am planning to put all on the same web host. All will be storing data on mySQL databases. My question.... if I want to use the same authentication details (user id and password) for all websites, which way you prefer: 1. Create the same member table in every database related to website, for example in websiteDB1, websiteDB2, etc? so every websiteDB will have membersDB? but technically all memberDB are the same because it's storing the same userIDs and passwords? 2. Create a separate database called memberDB and connect to it from website1 and website2 when the user wants to authenticate? what's you suggestion? Thanks, Jassim

    D L 2 Replies Last reply
    0
    • J Jassim Rahma

      I have multiple websites and i am planning to put all on the same web host. All will be storing data on mySQL databases. My question.... if I want to use the same authentication details (user id and password) for all websites, which way you prefer: 1. Create the same member table in every database related to website, for example in websiteDB1, websiteDB2, etc? so every websiteDB will have membersDB? but technically all memberDB are the same because it's storing the same userIDs and passwords? 2. Create a separate database called memberDB and connect to it from website1 and website2 when the user wants to authenticate? what's you suggestion? Thanks, Jassim

      D Offline
      D Offline
      dasblinkenlight
      wrote on last edited by
      #2

      This depends a lot on the expectations of your users: do they know that the same user name and password let them log in to multiple web sites, or do they expect to be able to change their password on website#1, and keep the old password on website#2? If user name and password must be kept synchronized for all web sites, then there should be only one table; if each web site should have its own pair of user name and password, then obviously there should be multiple tables.

      J 1 Reply Last reply
      0
      • D dasblinkenlight

        This depends a lot on the expectations of your users: do they know that the same user name and password let them log in to multiple web sites, or do they expect to be able to change their password on website#1, and keep the old password on website#2? If user name and password must be kept synchronized for all web sites, then there should be only one table; if each web site should have its own pair of user name and password, then obviously there should be multiple tables.

        J Offline
        J Offline
        Jassim Rahma
        wrote on last edited by
        #3

        what about using a separate db for the users profiles but instead of having a single record for the user id and password I'll use multiple records with a flag indicating which service this user id and password belongs to?

        D 1 Reply Last reply
        0
        • J Jassim Rahma

          what about using a separate db for the users profiles but instead of having a single record for the user id and password I'll use multiple records with a flag indicating which service this user id and password belongs to?

          D Offline
          D Offline
          dasblinkenlight
          wrote on last edited by
          #4

          It's a viable alternative, too, but given that you were planning on creating multiple databases anyway, this would seem like an extra maintenance headache. On the other hand, if your database would store little or no site-specific data (i.e. you're creating them almost specifically to support user logins), then using a single database with a flag in a table is definitely a better choice. A lot of this depends on your requirements: once you know what you are trying to achieve, doing the technical side becomes nearly mechanical :)

          J 1 Reply Last reply
          0
          • D dasblinkenlight

            It's a viable alternative, too, but given that you were planning on creating multiple databases anyway, this would seem like an extra maintenance headache. On the other hand, if your database would store little or no site-specific data (i.e. you're creating them almost specifically to support user logins), then using a single database with a flag in a table is definitely a better choice. A lot of this depends on your requirements: once you know what you are trying to achieve, doing the technical side becomes nearly mechanical :)

            J Offline
            J Offline
            Jassim Rahma
            wrote on last edited by
            #5

            actually it's different websites including personal site so i thought why should i keep all in one database and the scroll through the tables and stored procedures and ... and.... I am using mySQL and i thought it would be easier to have separate database for every website instead of putting all together or even create a schema because that might end up to large database size? what do you think?

            D 1 Reply Last reply
            0
            • J Jassim Rahma

              actually it's different websites including personal site so i thought why should i keep all in one database and the scroll through the tables and stored procedures and ... and.... I am using mySQL and i thought it would be easier to have separate database for every website instead of putting all together or even create a schema because that might end up to large database size? what do you think?

              D Offline
              D Offline
              dasblinkenlight
              wrote on last edited by
              #6

              If you have different databases for different web sites, and your users would need separate logins to each web site, then keeping the login data with the rest of the site data sounds like a better choice from the design perspective.

              1 Reply Last reply
              0
              • J Jassim Rahma

                I have multiple websites and i am planning to put all on the same web host. All will be storing data on mySQL databases. My question.... if I want to use the same authentication details (user id and password) for all websites, which way you prefer: 1. Create the same member table in every database related to website, for example in websiteDB1, websiteDB2, etc? so every websiteDB will have membersDB? but technically all memberDB are the same because it's storing the same userIDs and passwords? 2. Create a separate database called memberDB and connect to it from website1 and website2 when the user wants to authenticate? what's you suggestion? Thanks, Jassim

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #7

                Go with option 2, it sound horrible duplicating user profiles in each db. You could setup tables in your memberDB to control which app each user can login to.

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups