Am very new to azure federation.In my project there is an SQL azure database and now we want to use azure federation for scaling that database.
Is it possible to Federate the existing table ?.
How can I achieve this on my existing table casedetails. Am planning to federate the table based on customer_Id.From where should i begin.
in my scenario casedetails table against customerid which is the FK from Customer table.
Will it affect the queries used in the existing web application to fetch and insert values to the database ?.
How can i migrate data into the federated databse.. I am also facing a problem from identity not supported in federation. few of my tables contains identity specification and lots of data. Please reply if u have any insight relating to the problem.
Thanks in advance.
Related
The “Azure Cosmos DB for DocumentDB API Data Provider” does not seem to be actively maintained and I was not able to get it to work in D365 CE. I would like to use my Cosmos TB to be the source for some virtual entities in my CRM and the only way I can get this to work is writing a data provider plugin or creating an api. Is anyone aware of any other method to accomplish this?
I believe you will have to expose your database or
Particular table as Odata v4.0 webapi.
Or you could create your own data provider and expose your data through that data provider.
This is how data shall be available in virtual entity.
Note: your odata or custom data provider should respect field types of Crm.
For ex: 1 mandatory EDM.Guid field and so
On.
I want to create a new project on contract management system. In this I have to manage multiple organizations and want to create new instance in sql server dynamically for each organization in a saas environment. How is this posiible? I am using asp.net for development. Any help would be appreciated.
A true SaaS application has a single application and database. It has the ability to have multiple tenants use the application. All data in the database needs to know what tenant it belongs too.
For instance if you have a booking system: Your customers sign up to use the software and become a row in the customer table with an ID. When a booking is made it has a customerID column as a foreign key to the customer table. Then all reports, booking views etc are done for that tenant using their customer id. You as a service provider can then run reports on all customers/tenants for your own purposes. Multiple tenants can use the system and all their data be in the same set of tables. This then means when you need to cluster replicate backup etc it is a single db, and a single migration for schema updates.
See these wiki's on multitenancy and SaaS
This of course requires your DB schema (and your app) to support this - if you are unable to change the schema then there are a number of options to up a new DB based upon the technology you are using. If you are using code first EF, then there will be db creation and migration scripts you can use. Otherwise it may justhave to be a sql script you have to generate and then maintain and run this each time a new customer is required. Personally i would rather have a single DB with an appropriate schema.
Am very new to azure federation.In my project there is an existing SQL azure database and now we want to use azure federation for scaling that database.
How can I achieve this on my existing table myCustomer. Am planning to federate the table based on customer_Id. any relevant tutorial available?.From where should i begin.
By Federation do I have to change my existing queries used in the project.?
Thanks.
A rough summary of the changes you need to make to federate your database are:
Decide on an id you will federate on (e.g. user id)
For each table you wish to federate alter your table schema so the federation key is part of the primary key, and annotate the table so it knows which column is the federation key.
For each query that is run against a federated table you need ensure that the connection used is redirected towards the correct federation.
This last step is currently done by adding the USE FEDERATION statement to your queries. It can be a little tricky to implement if you are using Entity Framework or Linq. Something else to be cautious of in this area is making sure the USE FEDERATION statement is re-run if your transient error handling kicks in.
The links Alexander posted are all good to read.
Did you read the article by George Huey in MSDN Magazine?
It covers transition from an existing SQL or Azure SQL DB to a DB with federations in the section called "Migrating Database Schema from SQL Server or SQL Azure to SQL Azure Federation".
Right after that I would recommend to read the tutorial on data querying (part1, part2).
You will have to change your queries if they want to access the data from federations. Basically, every federation is an independent SQL database and you have first to establish connection to correct federation before querying for data.
There are also some peculiarities how to use federations with Entity Framework, partially due to additional overhead for connection to federation instance, and partially because federations do not provide support for MARS operations (article).
I have 2 questions.
I am developing a ASP.NET web application that uses the standard ASP.NET membership. We intend to have the membership tables in 1 database. We have 2 other databases that stores data for 2 different applications.
Shared - Membership info
DB1 - Application1
DB2 - Application2
Both applications uses the membership info in the "Shared" database.
The Shared database has a table called userdetals that will store additional users' info such as name, phone and job title for example.
However, DB1 also has a table called employees that store the same fields as name, phone and job title. Each employee may be an user.
Also for each table in DB1 and DB2, we keep audit trial, i.e. which user updated the tables in the database. Hence, we need to store UserID in the tables of DB1 and DB2.
We thought of having a Users table added in DB1 and DB2. So everytime a new user is created in Shared, the same user will be created in Users table in DB1 and DB2.
Our questions are:
What is the best way to maintain database integrity given the above setup? E.g. Each employee is assigned as an user. If any fields in DB1 such as username, name and phone is updated, then the same fields in Shared DB should be updated and vice versa.
Is it advisable to have membership database in a different database in our case? What is the best solution since almost all the tables in DB1 and DB2 references userID in the Shared database.
1.
The technology you are looking for is Merge Replication (http://bit.ly/KUtkPl). Essentially, you would create a common Users table on both databases, create a Merge Replication publisher on one application database, and then create a Merge Replication subscriber on the other application database. You could also set this up to synchronize the schema as well (which also means you only need to create the table once on the publishing database: it will push the table, schema with data, to the subscriber).
But if you are looking for more of a manual approach, I would not denormalize the user data to the employee(s) table, instead create a supplemental table and a view on each Application server. Kind of like inheritance in OOP: Any common data between the Employee table and Users table, leave on the shared user table. Any unique columns for the Employee, add to the supplemental table only and store on each database. The view would merge both the supplemental table and shared table. (http://bit.ly/9KPxt0)
Even if you do use Replication Services, I would still use this view design with the synchronized table.
You COULD update through the view, but I would not recommend that. It has been done before successfully in production, but there are too many constraints that could blow up (http://bit.ly/LJCJev). Instead update the table directly that holds the data.
Absolutely avoid "triggers that synchronize". Too risky (can cause an infant loop on your SQL server) and too much maintenance overhead.
2.
I would do the Merge Replication, it is just less for you to worry about and maintain after it is configured correctly. But your approach is OK if want something more manual or if you are not familiar with Replication services in SQL... just use the view noted above and you'll be set.
Easy way:
You can create link server to these databases.
And then create synonym to easy access to tables of each database.
Create trigger to update data when any data was updated on each table.
When using aspnet_regsql to create the base tables for forms authentication, is it recommended that these tables be stored inside of the application database catalog or should a database catalog just for authentication be created.
Thanks!
To clarify what jro said you can join across dbs but you'll lose some performance there.
Secondly if you want to maintain referential constraints you'll need the tables in the same DB. What I mean is if you have a new table for your app, say CustomerOrders, and you want to ensure the UserID column values exist in the Users table you'll need those in the same DB.
It doesn't matter.
If you need to eventually join records on the membership tables with your own catalog, I would suggest using an application database.
Otherwise, use your preferences for database management.