I am building an asp.net apartment rental website. Currently, I do not utilize any membership functionality so there is no need to create long-term users, manage profiles or any extensive user related data.
I, however, have a separate database that contain tables for (Units, Locations, Tags..etc) with a simple User table that contain the following three field: name, email and phone#. Note that when the offer of the unit has expired then the created user will be deleted form the database.
Putting scalability and best practice in prospective, should I create ALL the tables in one giant database (ex: in the ASPNETDB if I want to use the default asp.net membership provider) or should I keep the membership database separate from the apartment-related database?
No reason not to have it all in a single database - less maintenance over the long term.
Related
This is my first attempt, trying to integrate Membership on an existing shop already in production.
I'm not quite sure, based on my scenario, if I should use the build-in aspnet-providers or custom implementations of them in order to integrate membership.
Here's a few details:
I have a multi-tenant, single database, single schema web app based on subdomain.
The app is already in production and I will later want to link newly registered users with existing anonymous orders by email.
The development will continue after the membership integration, new features will be added, meaning new columns and linked tables for the users table.
This answer got my thinking of using the membership deafult Profile in order to extend the users table created by the aspnet providers, since I don't have users yet. Though its not clear to me how I would link Users with Orders and other tables/entities that might later be added when the app is going to be extended.
Maybe I could define my entities related to users as user-defined profile properties but they would not have associations on my database.
Another overhead I'm thinking of is how would I associate the users with the different tenants of the app. I would want users to be able to regiter in different tenants/subdomains with the same email.
How would you implement membership in this scenario?
This question is an aggregate of a few questions. I will try to answer them to he best of my knowledge
In case of managing users, i would like to suggest that you consider the following approach
Pre-define a list of basic user profile metadata that you will need in the application
Create an extensible approach like having custom fields for the user profile so that it can accommodate any data that may be required to capture in future
You should also be planning for a self-registration system in the application that will allow your user's to register themselves like the anonymuous ones that use the system with an email
Regarding associating the business entities, you will require to associate the entities with the tenant and not with the user. the level of application will be from the tenant and then it will flow down to the users.
Additionally, you should not have the user accessible business entities, when they are maintained in a form of package or so, it will be very easy to manage and use.
Share your thoughts on these approaches.
- Create a tenant identifier column [property] for each profile that identifies the base tenant to which the user belongs to
- create a table that manages the list of other tenant's that the user may be gaining access to at a later part
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.
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.
Is it better to extend my business database with the tables of the ASP.NET Membership Security model. Or should I have a different datastore where I only manage Identities and Roles... Basically 1 or 2 databases?
This can depend on scale. If it's an enterprise solution with different apps sharing one membership source the answer is simple - separate them. There might also be performance reasons why you would want to separate this data from the rest of the app. Arguably these tables do not belong in a data warehouse for example.
The only thing the 2 databases solution doesn't give you is referential integrity. If you extend your membership tables to hold more application specific details about the user, and these tables need to link into the main database then you might want to keep them together. Otherwise you would need some sort of replication job maintaining this for you.
This is quite subjective, but unless those users are going to be using more than one database, then I'd say keep them in the same db.
I would only use a separate database for users and roles if those users and roles were used in more than one database.
So no, I'd never use two. I might however use three.
Which database platform are you using? If one that supports schemas within a database, e.g. SQL Server 2008, then you can put your membership tables into their own schema, for neatness. You can also add cross-schema foreign keys if required.