Im developing a database application using MariaDB where I have a table for clients registers. I want them to be able to query the database, but I don't know if I have to create a database user account for each one in order to allow simultanious connections without collitions(same user trying to query at the same time) or can I use the same user account for simultanieous queries.
I'm kind of new to MariaDB.
Thanks in advise.
Databases are good at handling 'simultaneous' accesses by multiple connections to the same table.
The question of "one" versus "many" user accounts is independent of simultaneous access.
Most accesses work just fine without any problem. In the extreme, I suggest you read about "deadlocks".
Related
Here is the situation.
We have an Oracle 11g database where one schema user has a private database link to a remote database. When the user initiates a certain process, it pulls a large amount of data across and slows down the other applications. We would like to limit when this user can access this remote database by disabling the database link during certain times of the day and then enable it when performance is not an issue.
I have not been able to find a way short of locking the user or dropping the database link to do this. Changing the open_links system parameter, I believe, requires a restart and that affects the other database links as well.
Does anyone have a clever way to implement this kind of restriction?
Thank you in advance.
Yes, Solution is to enable Resource Manger. Limit the CPU or RAM as per your requirement.
You can enable 2 profiles , one with more cpu/RAM/IO and other with less resources and enable them as per your requirement.
Refer:
https://blogs.oracle.com/db/oracle-resource-manager-and-dbmsresourcemanager
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
I'm currently developing an app where the users are first asked to create an account trough a website (ASP.NET) to use the app. For a special reason I need to automatically generate a database for each customer creating an account, on the hosted SQL Server. The databases for all the customers are the same.
I was thinking about doing like that: as I have the script for creating the database, I was thinking to insert it in stored procedure or a trigger that will be launched as soon as the user has fully created his account.
I don't really see other solutions, maybe somebody could give me some guidelines? Thanks in advance.
I think such a design has been shown to not scale. I'd recommend redesigning the schema to allow multiple customers in a single database.
Amazon does not such thing. Neither should you.
I agree duffymo on you would have scalability issues.
However there are situations where in you might prefer separate database as your multi-tenant data approach.
In my last project I had to adopt separate DB approach as business wanted complete isolation for each customer. It was a school administrative system and number of customer was not expected to grow in more than three digits in 5-10 years time.
So the solution I designed was, I used Entity Framework code first approach. Every school will have a unique school identifier which will be used to name the database uniquely for each school. The connection string was generated at runtime obviously. A connection factory was used to create the appropriate DataContext based on passed school identifier. The database is created on first usage if not exist. At the same time SQL script was executed to create db users during db creation if not exist.
If this approach sounds appealing I can share code snippet if that helps.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.
I would like to do both of the following things:
use audit triggers on my database tables to identify which user updated what;
use connection pooling to improve performance
For #1, I use 'system_user' in the database trigger to identify the user making the change, but this prevent me from doing #2 which requires a generic connection string.
Is there a way that I can get the best of both of these worlds?
ASP.NET/SQL Server 2005
Unfortunately, no. Identifying the user just from the database connection AND sharing database connections between users are mutually exclusive.
Store the user from your web application in the database and let your triggers go off that stored data. It might even be better to let the web app handle writing all logging information to the database.