We are currently in process of developing SAAS application codename FinAcuity which will be hosted on Windows Azure platform and primary database will be SQL Azure.
Here are some Technical Specifications for our product:
Development Environment - Asp.Net 4.0 with MVC 3 (Razor), Entity Framework
Database - SQL Azure
Here is our Business Case:
Our product is a SAAS product, And as it will contains Financial Data of Client, we are going to provide separate database to each client to achieve higher level of multi-tenancy, Data Isolation & Security.
Now Client can create multiple companies under their account and these companies will be separated by Schemas under particular Client DB.
Note: Table structure will be same for each Schema.
Here are some scenarios to will give you a deeper view of our application processes.
Scenario 1:
To provision new database upon client registration, we are going to run Store Procedure that will create database with basic structure.
Our Doubt: Is this correct way of doing it on SQL Azure or there is some other way for it?
Scenario 2:
For accessing multiple schemas under client database, we have dynamically generated SSDL file for individual schema and used that file for connection.
Our Doubt: Is there any other way of doing it, like using same SSDL file instance for multiple connections and passing Metadata for connection?
Scenario 3:
As our application supports ad-hoc querying and dynamic table creation from Excel file, we are going to provide wizard that will run Store Procedure in back-end and create that table dynamically from Excel file upon header selection from wizard under particular schema for client database.
Our Doubt: Suggest us a better way of doing it, if any?
Scenario 4:
Now as the new table is added to schema, we have to update EDMX file to get data from that new created table. To do this we are going to run Store Procedure that will fetch data from newly created table.
Our Doubt: Is there any way of updating EDMX file runtime and getting data?
Need advice for best possible solution for each scenario that is listed above.
Thank you in advance.
Best Regards - Sahil
I think this is a little too much for 1 single question.
And I personally think you look at it from a wrong perspective. Why did you choose Entity Framework and SQL Azure? Do you really think these are the best technologies to address your problems?
I suggest you take a step back and investigate what other technologies could be used. Because what you're asking here looks like a schema-less solution, and SQL Azure / SQL Server wasn't built for that IMHO.
You can start by looking at a NoSQL (schema-less, key value store) solution, possibly in Windows Azure. There's a whitepaper that will get you started on that: NoSQL and the Windows Azure platform -- Investigation of an Unlikely Combination
Windows Azure Table Storage is a key-value store that could solve some of your issues:
Customer isolation / Multiple schemas: WAZ Table Storage supports partitions, you could partition your data per customer instead of putting all the data together.
Provisioning: No need to provision anything. Get a storage account and you can get started. Then you can simply have some code that writes data in a specific partition for that customer.
Cost (not mentioned in the question): Table Storage is much cheaper than SQL Azure
...
Related
My client asked to build an API in ASP NET Core for a business management application. Nonetheless, he made me an unusual requirement for me: He needs each user to have their own database. All databases have the same structure of tables and relationships and all are MySql.
This means that each user will need their own connection string and some way to store that information.
In addition, other users will be added in the future, each with a bank created just for their use.
Anyway, I don't know if this is possible, but if it is, how would I do it?
I posted this question yesterday:
Creating single application with multi dbs
So I decided that I should go ahead with the accepted answer thus meaning I should create an identity server which stores all users for all tenants. This will be separate from the actual application's api's.
Now I've come across a new problem. A lot of the POST api calls are saving things into the database which should be stored against a customer.
But this customer only exists in the identity database which is a database completely different from the applications database.
What should be done in these sort of scenarios? As I imagine people have come across this issue before.
My project is an ASP.Net MVC Website that has been deployed to multiple customers, and each customer has their own SQL Server database. As you'd expect, the data in each database is different, so even in development we have separate databases for each customer. The database schemas are identical. We have a custom database context extending DbContext and managed by Unity.
Currently we switch between these databases by either renaming the databases themselves, or editing the connection strings in Web.config (technically in ConnectionStrings.private.config, which we pull into Web.config using a configSource attribute).
How can I develop the same codebase against multiple customer databases at once, without editing any configuration when switching database? For example, I might have one customer at http://customerone.localhost/ and another at http://customertwo.localhost/ (different port numbers would be OK too). Each accessing their own database but sharing the c# code.
In apache I can use <If> or SetEnvIf to set configuration based on the url, but there doesn't seem to be an equivalent in IIS. When I try to change it in c# code I am told it is read only.
To be clear I don't want any changes to be written back to web.config - I just want the custom database connection string to be used for the life of the request.
It seems MVC 5 no longer uses simple membership and I am having trouble figuring out how to use a SQL Azure database instead of the default .mdf file that is generated and saved on the web server. In simple membership it was as easy as changing two connection strings but that does not seem to be the case here. From what I have found online, it seems like I have to create my own custom storage provider to accomplish such a simple task. The only examples and docs I find online that deal with Azure are scenarios in which the developer wants to store in a non-relational setup or Azure Table storage.
Am I right in the above conclusion or is there something I am missing about integrating SQL Azure DB into my MVC 5 Asp.Net Identity app?
I have Identity running on top of a SQL Azure DB in one of my projects. You don't need to implement your own storage provider. The only thing you have to do is to change the connection string (normally named DefaultConnection) in your web.config file and point it to your SQL Azure DB.
I am currently working on a ASP .Net MVC 3 application to do some database manipulations on a specific set of Metadata tables in a database. I'll basically be doing inserts, updates deletes etc. from the application. However, the aim is to migrate these Metadata tables across different databases (and most likely servers as well) so that we can use the same Methodology across clients.
Right now I am using Linq2Sql to generate my ORM around these specific metadata tables. The aim is to use the same application to manipulate the data across servers and databases. What is the best practice/approach for this?
The simplest solution that I've thought of is a constructor for my DataContext where I could use user input (server + database name +userID +password) to manipulate a connection string and pass it into my DataContext. Since the Framework should be the same across all databases and servers, this should work in theory. However, I'm not where the best place to maintain the modified connection string is (The session? a cookie?).
What is the best practice around this kind of server/database switching in a .Net app?
You're going down the right path by passing the connection in the constructor for the context. As for maintaining the connection string, I suspect that would depend on how you are managing the other site information for your various sites. If you are managing that in a central database, save the site specific value in that central database and use the same persistance you are using for those site settings while the user is visiting your site. Just make sure not to pass server specific information to the client (thus a cookie would not be the recommended approach).