Im writting a RH system witch consist in two "services":
Web App - For RH recruiting management companies
Web site - For people and companies to seek/register CV
The two things use the same databases for all data... my question is about the users... im the WebApp, the user HAVE to be attached in a Company (my clients).. .but in the website... dont... just regular users registering CV and searching for a job!
How can i manage this two kinds of users??
I thinking in use two separate tables for each kind of user... this is a good aproach??
Tkz
Roberto
I would keep all of the users in the same table, but for data that is "required" for users that don't have it, have a default "company".
Perhaps have a generic "company" that is called "Job Seekers". This would allow you to group all of the searching people without forcing you to maintain different user types (which becomes difficult to manage).
Users are users, I'd keep them all in one table. Use a separate field, or a foreign relationship with another table to distinguish between the two types of users.
Related
I am a novice in SQL organization! I essentially have an inventory app written in php with an sql database. If I want to allow multiple users to create inventories independent of one another using my web app, would I just use foreign keys linked to a user table or should I be creating new tables for each user, or another option that I have not considered?
thank you!
I have said before that it's a code smell if you hear the word "per" in the context of of database design.
I'm going to create a table per user.
That could result in a lot of tables. How many users will you have? Hundreds? Thousands? Millions? Can your database handle millions of tables? How can you test this? Does that mean your application must create new tables on the fly as new users register?
In your application code, would you create a separate PHP class for each user? Probably not -- you'd create one class that can be reused for many users. One of the class data members would distinguish the user, so each object instance of that class is for one user. But it's the same class.
Likewise, it's almost always better to create one table, and make sure the table includes a column to identify the user. It's simpler to add new users by INSERTing new rows into the table, instead of requiring new tables to be created.
There are exceptions to every rule, of course. You might have so many users that you must split the database over multiple database servers. Or you might have a very strict privacy requirement and separating the data into multiple tables is a good way to enforce it. But if you're just starting out with a small project, those exception cases probably don't affect you yet.
Friends, I am building a service application and would like to see a gross suggestion to achieve.
The core of the application is to manage research projects, hence it will have a group of users, who belong to an organization, who login and manage their own projects. Many organizations carry out such projects, which are identical in nature. The project management has identical database tables and schema (across institutions). I have designed a plan as follows:
Database-1: A common database users table (all institutions together) get authenticated by querying this table. This table has a institutional code corresponding to each user as a column.
Database-2 (institutional code as its name): Based on the institutional code, all the project management is done by connecting to this database. Within this database tables will be present.
....
Database-x (institutional code as its name).....
All databases will have identical schema and identical user interface. Institute wise management is easy this way.
Now, using Laravel, i know i can connect to multiple databases. I have done this in codeigniter 3 but trying to migrate to Laravel 5.3 as models architecture is different between Codeigniter 3 and Laravel 5.3.
Any better suggestions. I know my query is not a pure question but this question is about implementation of a many to many relation.
Since all institutions will have same modules and same functionalities why are you creating multiple databases? I have successfully done a similar project as you, a Centralised CMS which integrate all church under one diocese in CodeIgniter.
Just add an institution id in all tables and query your table operation with institution id every time. Adding multiple databases will definitely decrease your project performance and increase complexity. An institution table will track all your institutions.
If you need more details about database structure and implementation please comment below.
I have successfully worked on mutliple database and mutltiple domain application.
In that I have created one table "branches" which stored the multiple branches details
like its database name, domain name.
I have set the record as domain= "branch1", database="db_branch1" in table "branches"
Also set the middleware which check the valid domain name and allow to associated routes for domain "branch1".
Once the main common database authenticate the user creditials it connect to branch database in main connection.
It can not explain in very short method, here I just explain the work flow. If you need more details I will explain it.
The application I have to design is the following:
A group has several functionalities that each user can access and
work with. It is not a chatting group. It it like having data that
each user can add/edit based on his privileges.
Each user can create or join as many groups as he/she likes.
My question is what is the best way to design a database for such task.
Examples similar to what I want to achieve exist on live sites such as:
Deviantart's groups, Trello, Facebook's groups, LinkedIn company pages etc
I have two ways that sound good but I may miss something important:
I was thinking that one database is the best way, and create
associations with the groups and the users. This way though makes me
think about performance. What will happen if/when there will be
thousands or even million of users and maybe more groups available.
Will a mysql database handle all the requests and respond quickly ?
An other suggestion was made to me that I could split each group
into different tables. So when a user connects the requests that
will happen will be only based on the groups he/she has joined. Only to
those tables. With that approach I see a database full of tables
that will not be able to manage later on, as more groups get
created.
Am I overthinking that I will have performance issues ?
Is there a technology that I am missing that could help with my situation ?
This application will be developed in laravel 5 with mysql database and angular 2.
Thank you in advance!
John,
Have a nice and creative day!
A user signs up, they can create a group and follow other groups and add items to groups.
User table design example:
id|email|username|password
Groups table design example:
id|user_id|title|description
user_id = person that created group.
Items table design example:
id|user_id|title|content
user_id = person that added item.
GroupUsers table design example:
id|group_id|user_id|role
role = admin or moderator or follower or whatever you want that user to be able to do for that group. You can have the same user_id assigned to many group_id.
GroupItems table design example:
id|group_id|item_id
I wrote this out quickly and may not be perfect by any means, this should give you an idea of one technique. If you do not understand relational databases. Please go learn.
I'm working a site for invoicing and inventory, and I need two different kinds of Authentication, one for clients and other one for users (sellers, administrator). I know it would be easier to have a single table Users with a field like user_type, instead of having Users and Clients but I need this two tables individually because they interact each other and also have differents behaviors. What do you think I should do for an efficient authentication?
I think what you want is permission groups. This way you can add a group called clients and one as administrators or sales. I would look # Sentry by Cartalyst. I use this to manage 13 groups. This also has the ability manage permissions and write conditional statements on permissions.
No idea what your software does but it looks like you need to do some reading on pivot tables.
My guess is that you have "clients", "Users", and "Invoices"? and need each invoice to have a client and a user? Maybe several of either?
All of you members, client or user, in the same table. Make sure to give them all a 'user id' of some sort.
'Invoice' table, same as the last two.
Pivot table would be member_to_invoice. This would be a many to many pivot (i think) and would simply have (invoice_id, client_id, user_id).
This would give each invoice a member and a user. The drawback of this would be that a member type is only set by the invoice. So there wouldn't be a way to have a client log in that was different then a users. Though that might not be a drawback depending on what the system does.
You could set it up the other way as well with another table 'member_type' and pivot that off the member table. This would give you separation in the member types. Then you wouldn't really need the member_to_invoice pivot unless you needed multiple users or clients attached to a single invoice.
For a project we would like to use multiple databases containing different kinds of users. The website is divided over multiple subdomains. That means: 1 subdomain has 1 database. We have 1 central database to keep up with the existing subdomain databases.
In the central database, we have administrator users that must be able to administrate every subdomain application. In the other databases we have subdomain specific users. Users are stored as Doctrine entities (FOS User bundle for Symfony 2) and are tied to other entities (foreign key constraints) by their id's. The entities are the same for the central database and subdomain databases.
The users must be bound to subdomain specific entries (read: instances of entities). For subdomain specific users this will be no problem, but we have no clue how to achieve this for administrator users (which are in the central database). The foreign key constraints can not be met, since the administrator users do not "exist" in the subdomain specific database.
Refactoring some of the entities would be no problem. We hope you guys have any advise for us. Thanks in advance.
P.S.
We are able to switch between all databases easily. This is possible throughout the whole application, except for the login. This is handled by the FOS User bundle
I suggest you to use one base user entity for all users in the subdomain, in a centralized place, and for each subdomain, there will be an extended user entity, with extra information stored, related to the specific subdomain. Possible structure for that can use single table inheritance, but it is not a must.