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.
Related
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.
I'm thinking of implementing blameable fields to couple of my tables using https://github.com/stof/StofDoctrineExtensionsBundle bundle to know which user created some of database objects.
What I want to achieve and cannot find right answers to do that is following:
As admin user I would like to be able to transfer all blameable objects from one user to another one. This could happen in cases when I want to delete existing user or just want that those objects belongs to another user.
Theoretically I can connect to MySQL.INFORMATION_SCHEMA to find all tables which have fields "createdBy" and deal with those tables, but I cannot connect to that database using doctrine (or can I???).
Can someone suggest approach of transferring all blameable objects to different user?
P.S. I don't need to set default user or to enable null values for createdBy column like answered here: How to disable Blameable-behaviour programmatically in Symfony2
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 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.
Let's say I have three tables: users, books, and users_books.
In one of my views, I want to display a list of all the books the current user has access to. A user has access to a book if a row matching a user and a book exists in users_books.
There are (at least) two ways I can accomplish this:
In my fetchAll() method in the books model, execute a join of some sort on the users_books table.
In an Acl plugin, first create a resource out of every book. Then, create a role out of every user. Next, allow or deny users access to each resource based on the users_books table. Finally, in the fetchAll() method of the books model, call isAllowed() on each book we find, using the current user as the role.
I see the last option as the best, because then I could use the Acl in other places in my application. That would remove the need to perform duplicate access checks.
What would you suggest?
I'd push it all down into the database:
Doing it in the database through JOINs will be a lot faster than filtering things in your PHP.
Doing it in the database will let you paginate things properly without having to jump through hoops like fetching more data than you need (and then fetching even more if you end up throwing too much out).
I can think of two broad strategies you could employ for managing the ACLs.
You could set up explicit ACLs in the database with a single table sort of like this:
id: The id of the thing (book, picture, ...) in question.
id_type: The type or table that id comes from.
user: The user that can look at the thing.
The (id, id_type) pair give you a pseudo-FK that you can use for sanity checking your database and the id_type can be used to select a class to provide the necessary glue to interact the the type-specific parts of the ACLs and add SQL snippets to queries to properly join the ACL table.
Alternatively, you could use a naming convention to attach an ACL sidecar table to each table than needs an ACL. For table t, you could have a table t_acl with columns like:
id: The id of the thing in t (with a real foreign key for integrity).
user: The user the can look at the thing.
Then, you could have a single ACL class that could adjust your SQL given the base table name.
The main advantage of the first approach is that you have a single ACL store for everything so it is easy to answer questions like "what can user X look at?". The main advantage of the second approach is that you can have real referential integrity and less code (through naming conventions) for gluing it all together.
Hopefully the above will help your thinking.
I would separate out your database access code from your models by creating a finder method in a repository class with an add method like getBooksByUser(User $user) to return a collection of book objects.
Not entirely sure you need ACLs from what you describe. I maybe wrong.