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.
Related
I am planning to make a software (ASP.NET 4.6.1 MVC with Entity Framework), which does a lot of reading from DB. Therefor I have one database, which contains all global information, projects etc. and now I am thinking to either bring all the content into the same DB but in different tables or to create a DB for each bigger group.
Now as there is a lot of reading going on, is it bad practise to have the connection information in the main db and then to connect to a different DB? Otherwise I would have the project information in the primary database and the content in a different table on the same DB.
Are there any notable delays to connect to a different DB to retrive the information?
If it's all your data, for your application, it should all go in the same database. Definitely use different tables. You should read up on entity design and normalization... and if you really need to do that, you may already be in over your head.
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
Our requirement is something like this.
We are building a multi-tenant website in ASP.NET MVC, and each customer should be able to create their own users as per predefined user roles.
We are thinking about to create a schema for few tables which would be common for customers. So customer can login to system according to their schema logins and we need not to alter any queries to serve all of them.
We are referring http://msdn.microsoft.com/en-us/library/aa479086.aspx Shared Database, Separate Schemas.
Can someone suggest on following
1. After creating schema how to authorize user against a particular schema
2. Is this possible that without any changes in queries db can serve multi-tenants
Thanks in advance
Anil
After much research, I can say that, although it takes more development up front and more checks along the way, shared database and shared schema is the way to go. It puts a little bit of limits on how easily you can cater to a client's specific needs, but from my point of view SAAS isn't about catering to a single client's weird needs. It's about catering to the majority of clients. Not that it's a SAAS but take iPhone as an example. It was built to cater to the masses. Rather than focusing on doing everything it's built to be one-size fits all just by its simplicity. This doesn't help your case when it comes to authoriztion but it'll save you dev hours in the long run.
If you are asking this in the context of SQL Server authentication/authorization mechanism, i can asnwer this question with saying that every user has a default schema which helps query engine to find out required object in the database.
SQL Query Engine will look at the user's default schema first to find the required object (table). If it founds the object in user's schema then use it, otherwise goes to system default schema (dbo) to find it.
Check this article's How to Refer to Objects section to find out how it works. The article also has some information about security concepts related to schemas.
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.
We are going to be selling a service that will be hosted by us, and each client we host will have their own database, but there will be one centralized website. I currently have a blank database with the few things that a new client will need. What is the best way to copy this database so I can setup another client? I want to be able to do this from an .aspx page. Thanks in advance!
Update:
By .aspx page, I just meant that I need to be able to kick off the process from an .aspx page.
Update2:
We're running SQL Server 2008.
Update 3: Referencing Cade Roux's answer... Thanks for a great answer, but...
What is the reason for merging all of the databases into one, and then distinguishing clients based on an identifier in each table? Wouldn't this greatly complicate the architecture of the entire product? I would need to add these Client ID columns to practically every table, and the DAL would need to know which client data its looking for. With the current setup I have, I just switch out the connection string in the DAL, depending on which user is accessing the site. That way, after the connection string is set, I never need to worry about finding client specific data! How do these approaches compare (and should I add this as a separate question?
You have a few different options:
You can detach your empty database, then when a user signs up, copy that database and mount it under a unique name for them and map it to their account in your master database, say.
You can create a database from scratch using scripts and populate any base data either from an online template database or scripting the base data and map it to their account in your master database.
You should seriously consider going to a multi-tenant architecture where all users are in the same database (with most tables having CustomerID columns to segregate the data) if you are going to have more than a few dozen customers.
Regarding your notes about option 3 - it depends on your application. Multi-tenant can be difficult to retrofit. On the other hand, managing and upgrading hundreds of individual customer databases can be difficult in the long haul.
There are previous Stack Overflow questions regarding this:
What are the advantages of using a single database for EACH client?
One database or many?
I think I'll see about re-tagging them with multi-tenant-db or something. Anyhow, I think that this comes up as a consideration secondary to your answer about a particular tactic does show the importance of including details about your overall goals in strategy in every question on StackOverflow.
Depending on what database you're using, there are several approaches. The simplest is to ask your database software to generate SQL code for creating the database and include that with your software. Another would be to just script out in C#/VB the steps needed to recreate your empty database.
Why the need for .aspx page?
You don't say what db version you're using but in SQL2005-2008, you have the ability to "script database as" and then "create to" and have it port the sql to a query window. You could then work with that to create a stored procedure that can be called from your .aspx page.
SQL Server has a system database called 'model'. Any database objects (tables, views, stored procedures) that exist in the model are added to any new database created.
You could create your 'client database' schema as model, and any new database would have all the same tables...
But, if you need to change your database schema later, your best option is to write change scripts which are part of your code-behind file. Since changes to the 'model' database are not propagated to existing databases, the application needs to detect and upgrade the database schema as necessary.
Disadvantage to this approach: If you want a database which isn't a 'client database' then you would need to create the database, and then delete the 'client database' tables.