I have a users table for registered users. These registered users can add contacts that have registered (Registered users) and also contacts that have not registered (That can register in future).
What is the best database structure?
Should I create two User tables (Registered and unregistered) having
ID as primary key and using the Email as a unique identifier.
Should I store all contacts (registered and unregistered in the same
table #Users Table) having in mind that not-existing users/emails
can be added to the table making it to have alot of users that may
never exist.
I manage a website since 6 years and I have all the users in the same table with a column named "profile", with any problem at all. Is very useful to have all in the same table.
You could have a boolean column: registered and non registered.
No need to create two tables you can create separate column for user_status it can be registered or not and email can be a unique column and for non registered users it will be null (violating normalization principals ) but it will work for you
To stay nth normalized and flexible in your design to use Contact information for purposes beyond even your description I would go with.
Contacts Table -- everyone with shared contact details
Users Table - specific to users and details in regards to user accounts (e.g. encrypted/hash password and email)
Now if you only want a 1 to 1 relationship between User & Contact simply include a foreign key to Contacts Table on the Users Table.
If you want to allow for a one to many, or many to many use a 3rd table to store relationships between users and contacts. I would see this as rare and it is definitely very difficult to manage, but I have learned from my own guest data environment that email addresses are never really unique to an individual. Families share! Husband wife, kids, etc. Also depending on what you are selling/doing the same person may want 2 accounts 1 for business and 1 for personal, Or 1 she doesn't care about her husband seeing and 1 she does. Plus if you ever want to allow for groups to use the same account you might want to capture all of the contact information.
Related
I have a user table setup where a user can either belong to a Supplier or a Customer organization, which can have multiple users.
My original idea for the User table was to have a customerID and a SupplierID in the user table, out of which one will be filled, based on the organization the user belongs to. This does however not feel right, but I feel like maintaining two linking tables for this is overkill as well.
What would be the best practice in this case? I do not expect there to be any more organizations added in the future, but I do want to futureproof the application, by allowing multiple users to belong to the same organization.
you can design user or organization table with a column organization type which has value: supplier/customer and a column for organizationId
I need to make a user table in an education database where a user can have the following profiles:
1. Admin
2. School Admin
3. Tutor
4. Student
5. Parent
6. School Teacher
Now, the question is weather to make separate tables for each profile and use a key in the user to table to link with profile table or keep all in one and add a profile key to identify the type of user. Everyday new users are added in the database so its a growing database.
The queries which are run to fetch the data are specific to the profile. For example, the data will be fetched for one profile at a time. But, what about the cases where we need to get all the teachers of a student or all students of a teacher? In that case I will have to store the id of the student in the tutor and teacher table. What is the optimized way of going about it?
I will suggest to make separate tables for profile and use a key in the user to table to link with profile table (if profiles are pre-configured)
if profiles are dynamic then you have to take care in your application like check profile exists or not, if not exists then first insert into profile table and then insert into user table. This may affect INSERT performance.
to get all the teachers of a student or all students of a teacher, you have to use self-join
I'm having trouble with database design, for tracking visitor activity for a mixed group of users.
Some of the users are logged in on WordPress, and thus have IDs. Others are guests, so I want to assign them a unique ID that won't clash with the WordPress ID, and store that as a cookie.
Database normalization, as I understand it, calls for an activity table, and a separate user table. But the logged in users already have a user table in WordPress, and I don't want to clutter that table up with guest entries, since the table has a lot of fields, and all I really need to know about the guest is that the ID is unique.
Should I just create an additional two-column user table, with tracking ID the primary key, and a field for wordpress_id that is empty for cookie-guests?
Or do I even need a table for the guest IDs - is it enough their IDs are unique? Just assign guests a negative ID number so they never clash with the WordPress ID?
Having a difficult time with this design, guidance is greatly appreciated.
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.
The following screenshot is ERD for one application or one business. If you have used QuickBooks youll know that it has starting form called company so in one application we can create many companies and maintain company accounts
if I add a column companyid to all table then I can add many companies in one application
what is the good practice:
Adding company key and exacting company info with company key
Creating database for each company if thrs 100 companies 100 mysql databases
please advice !
Creating a separate database per company is almost assuredly not what you want to do (unless you have a really good reason to need to do so). Adding a company_id to your tables and ensuring that columns you query against are indexed with company_id along with whatever other column you will typically be querying would be wise.
You'll also need to ensure that your application is designed to correctly inadvertent (or purposeful) access from one company to another company's data.
EDIT - Now that I see your ERD has been added: I would add a "company" table containing a company_id, name, and whatever other data you like, then ensure your other tables have an additional company_id field as well.
Since you want to maintain all companies' businesses and accounts within the same application, then there is no need to create a database for each company, just add a Companies table, then add a foreign key company_id to the other database tables