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.
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.
I am working on a project with a bigger database structure then I have ever used before. I have questions regarding accessing certain tables.
I am now designing my ERD and have several Module tables
"Modules", "SubModules1" and "SubModules2".
As shown in the diagram below, Modules has an 1-m relation with SubModules1 and SubModules1 has a 1-m relationship with SubModules. There is a Bugs Table in which I want to store bugs linked to the module or submodule it belongs.
Question:
Is it necessary to connect all the Module Tables with Bugs Table separately, or is it possible to access all the SubModules through the Module table, since that one is connected to the SubModule1, etc...?
Note: Requirement is Data must be accessed from DB using PHP + Laravel 5.3 Framework
I'm designing a web application that allow user registration. That's pretty simple to persist, since a new user is a User entity class that only represents a new line inside a users table in a database after created.
Those users, after logged in, may create a new Group, also registered as an entity class. This group would also represent just a new line in another table called groups. Everything until here is extremely simple, even for someone like me that only watched a few Lynda video tutorials on Symfony2.
The issue that is preventing me from going further in my development is that the users, weekly, will have to register reports for these groups, that, as the other, will be referencerd as a Report class in the Entity folder. I know that these registers could simply be added to another table reports, with a mapping OneToMany, relating the group to the report with a group_id column or something like that. But, someday, this table may be, I don't know, a million rows long?
So, I was wondering if there is any way to create a new table {groupname}_reports in the database each time a user creates a new group in the web application, in order to make things a bit more organized. Also, how could I send the connection to the correct table using the group name as a parameter?
Thanks in advance!
i'm using codeigniter.
i'm limited to 1 mysql database.
if i have a web application with many tables for use on 1 company.
i would access it like:
http://www.abc.com/login
http://www.abc.com/member/sales.php
if i want to use the same application for other companies in the same database, how should i proceed? and how can i access it using codeigniter?
i can't seems to figure it out.
many thanks for your guidance.
Try to create a table names with the prefix of the Company name that will give the clarity of the table names also...In the code u can easily identify the Name with the prefix.
I guess in your case codeignitor is mere a development framework not more than that so try to create a seperate table with name of companies and use PID of company table for identify all the records related to the company.
Or if creating schemas is not an issue than codeignitor provides you facility to connect more than one database at a time, please go through following link -
"Connecting to Multiple Databases"
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.