i have ASP.NET website with ASPNETDB.MDF database from default providor.
i have also MainDB.MDF that contains all other site database.
i want to combine ASPNETDB.MFD into MainDB.MDF in order to have only one DB.
is it possible?
if yes what are the disadvantages of this combination?
The only theoretical disadvantage is that you may want to run several apps with shared users. Then it would be better to have external provider. Most people don't do that of course then it is better to have data and users in the same database to make deployment and backup easier.
To achieve this just run the asp.net regsql tool against your database and it will create the tables. Then have just one connection string to your database and you are done.
Related
I have to have my security in a different database, because multiple applications use the same security database.
I want to be able in one of my models in a project to reference a user virtually. I can't do this however, since it would create a foreign key relationship over different databases, which is impossible.
I also have a common configuration database where several applications use the same config tables, and have the same problem for the same reason.
What's my best move in this situation?
Thank you.
in my web site i have two databases, ASPNETDB.MDF and a self created one (database.mdf). (The don't contain a lot of data yet)
But i need a relationship (foreign key) between a table in ASPNETDB.MDF and a table in database.mdf.
So i guess i need to merge both databases first, would you just extend the "ASPNETDB.MDF" with the tables from "database.mdf" ?
or better configure "database.mdf" for the asp.net Applicatoin Services and then delete "ASPNETDB.MDF" ?
Is "ASPNETDB.MDF" even meant to be used in a production online web application?
(Right now i'm using sql server express but i will probably use sql server when deploying Site to a shared host)
thanks a lot for answers
the scripts for the structure that is inside ASPNETDB.MDF are deployable on a different database (http://msdn.microsoft.com/en-us/library/x28wfk74.aspx)
however, I would really consider wether or not you want to do a foreign key to those tables, the membership, roles and profile API is intended to be used as a pluggable API, something you will break by defining your foreign key
Setting up membership in existing database is something you should be looking at. If you are asking me, I will and I have created membership related data objects in my application specific database. You can find the SQL scripts to do so at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727(v4.0.30319 in case you have VS 2010).
By doing this you can create foreign keys to membership table and achieve your objective.
I'm pretty new into asp.net, and currently I have the need for storing various information in a database. Since I have used the standard Login control in asp.net, I already have the ASPNETDB database in my application.
My question is: Is it good practice to use this database for other things than user and role information?
Regards, Casper
Best practice would be to store the user/profile information in your normal SQL Database, therefore not using the ASPNETDB, but migrating all the tables and data to your application DB.
I'm in early development stage of developing a web application. Im currently reviewing as to whether I should use ASP .NET Membership or write my own. Im more lenient towards to using ASP .NET Membership to save me some development time. Need help to clear up some ambiguities on how to best utilize membership database:
Membership creates a new database. Which one is better, to use the same database for my
application database OR creating a new database for my application? Why?
If I go for creating a new database for my application. Which one is better, creating a new user table in my application database or reusing/extending the user table in the membership database?
Thanks in advance,
RWendi
I myself am a fan of the Membership/Roles/Profile providers so I'm a bit biased. Basically if I were to evaluate what to use for a project I would look at the requirements. I can see no reason to implement your own membership functionality if the default works for you. It has many features and some pretty good optimizations (like columns with lowercase username and email for performance reasons).
I usually create a single database for my data and my membership. I link other tables by adding a username column but not a foreign key to avoid problems with deleting users. What is more the GUID that is the user id cannot be retrieved with the membership provider interface and you will need to write your own stored procedure if you want to reference stuff by user id.
On the question of separate database or not, separate tends to be the way to go if you have the resources (eg--you aren't on a shared host with a single sql server db). The main advantage is that the user data tends to be pretty application specific (eg--you don't need production user data in QA), so having it live separately makes things a bit cleaner as you only need to schlep about the application's data.
If i use a separated ASP.NET Membership database what is the correct way to define the relations between the user tables and application data tables?. Should i create copies of the user tables and sync? or is ok to just create the Guid columns and enforce validation in the application code?, Are there any issues with performance that i should be aware of when separating databases?
You can Create two database , one for Membership control and other for Web-site use.
I have Many sites which are running on same concept. No need to worry. web-site will be fast and secure.
If you want to learn more on this or want a live demo then download a classified starter kit for asp.net
Just make the join on databases(with double dots) when you need data.
No need to change, just handle the userid, role etc but need to create two different connection string in your app.
OR Copy the tables in your original db