Is it better for a collection of ASP.NET web apps to share the same session database, or should each one have its own?
If there is no significant difference, having a single database would be preferable due to easier maintenance.
Background
My team has an assortment of ASP.NET web apps, all written in either Monorail 1.1 or ASP.NET MVC 1.0. Each app currently uses a dedicated session state database. I'm working on adding a new site to that list, and am debating whether I should create another new session database, or just share an existing one with another app.
The original question was "Share the same Session Database". I see this as different from the Application's Database. ASP Session for all applications would be the same. You would not be modifying the Schema for any of the Session Tables, SP's etc... We host a number of applications, each with their own private Database for the aplication data, and a single shared Database for session.
I would vote for separation here.
I don't think you'll necessarily find that it's "easier maintenance" in the long run to stuff everything into one database. If every app is using the same table and database instance, you can't separate one application from the pool without duplicating the entire database. What if one app goes viral and needs to be moved to it's own server cluster?
For the amount of work it takes to copy a database to a new instance, you'll be separating the concerns of the applications, making it easier to debug them individually, more scalable and much more portable.
Related
I have to different ASP.NET applications (same version) running on the same IIS Server and I have Sessions running In Process. Will the session state/variables persist across the two applications? I found a similar post where someone asked the same question but they were managing sessions in SQL Server and someone pointed out explicitly that session state doesn't persist (out of the box) across two applications of Sessions were maintained using SQL Server. It made me wonder if the same applies by default for two applications where the sessions are maintained in process.
No there is custom code needed.. best way that I found to do this.. is to have the referring page pass its session id and application name, then SQL stores the Session Data in a table using the [sessionid][appkey]... we use a reference table that I manually build to figure out the appkey for each new application... then I wrote a DLL that takes the string in and pulls the sessiondata from the DB and packs it in to the new pages current session.. Its a little tough to wrap you head around, but I can supply the DLL and how to use it if you want. Just PM me and ill get that DLL for you.
I have a web site I developed for displaying the results of some data analysis work I did. It relied on ASP.NET for the front end and connected to a MySQL back end utilising Entity Framework and LINQ extensively.
I chose MySQL because I personally have used it in the past and like the database, but this resulted in some serious issues when I had to deploy it to a hosting provider (incompatible connectors, access rights, etc.)
I am now getting ready to redevelop and expand the site and I am looking for some advice to avoid the issues I had last time.
The new DB has to serve two roles. The first is to be a data provider for the charts that are the output of the analysis work. These tables are straightforward, almost flat files, with 10 tables. One table has roughly 200k rows of data the rest have aprox 1200 rows of data each. There are little references or queries between the DB tables, but there are a few. This data is updated periodically by a back end process and does not need to be added to or edited by the user.
The second role of the DB would be as a basic persistent store for a standard user management system. It would need to manage data for adding/ removing clients, user names, passwords, access rights. etc. No financial data or super secure data is involved.
What database approach would you recommend that would give me easy deployment and management at a web host and still allow me to use both Entity Framework and LINQ effectively.
Second, what tools/frameworks should I consider as I rewrite this system. It is very graphical and data focused. Presentation of charts and information is the key factor in this site. Are there any new technologies or frameworks that would add specific value to what I am doing?
A few notes. I am a one man shop and I maintain the entire system myself so I am less worried about enterprise level frameworks than other people. My focus is on the easy development and deployment of the site. Maintainability is also a key factor.
I am also an experienced C# developer, but new to ASP.NET and the web side of things. The first version of this site was a big learning experience. It was good, but I wasted an enormous amount of time on just understanding new technologies and approaches. I am very open to learning, but I can't afford the time to get my head around a complete paradigm shift.
I am looking forward to your thoughts, thanks.
Doug
The natural choice would be SQL Server. I'd guess by your description that you are way under the maximum space limit of the SQL Server Express edition. I of course supports Entity Framework and the drivers are part of the .NET Framework, so no problem with third party assemblies here.
This will also open up the possibility to host your app in the cloud (Azure) later on, because SQL Azure in fact is a Microsoft SQL Server, so there is no overhead in supporting that.
Regarding user management - ASP.NET has this all build in (Membership, Role and Profile provider) and also a SQL Provider for which default tables are available. So you don't have to design your tables by yourself and it runs very naturally on SQL Server.
I have three different applications, they all share the ASP.NET membership aspect of the database and almost definitely they won't share anything else.
Should I have a separate database for each of the applications, or would one suffice?
All the application tables are prefixed, so that wouldn't be a problem in integration. Although I was wondering if there would be any performance issues, or if having all three applications share the same database would be some kind of grave mistake.
The applications in question are three web applications, the "main site", a forum and a bug tracker. I'm wondering if this is viable because integration could be easier if I had a single database. For instance, the bug tracker registers asp.net membership tables in it's db connection, and it even creates an "admin" user, where the db that is actually supposed to be holding the membership tables would be the "main site" one.
Update: I added a bounty to this question since the answers seem to have pretty split opinions about whether I should or not use multiple databases for different applications that share only membership providers.
Separate apps = separate databases - unless you have to "squeeze" everything into a single DB (e.g. on a shared web hoster).
Separate databases can be backed up (and restored!) separately.
Separate databases can be distributed onto other servers when needed.
Separate databases can be tweaked individually.
I have always found it would be better to have more databases so that it is easier to:
Migrate to more servers if needed
Manage security / access easier
Easier (and Faster) restores and backups
I would actually go with four databases. A Membership database, and then one for each application (if the membership is truly shared). This will allow you to lock security across applications as well.
Looking at your question closer... You say that the data would "likely not be shared"... will a lot of your queries be joining tables with the membership? If so, might be easier if they are in the same database. However if you are going with a more entity based approach, I would think you would still be better with multiple databases. You might even want to look at something like an LDAP database or some other type of caching for your membership database to speed things up.
You should use the same database unless you have a current need to place them in separate databases - HOWEVER where possible you should architect your system so that you could move the data into a separate database should the need arise.
In practise this means that you should keep SQL procedures working the smallest amount of data possible - i.e. Don't have multi-step stored procs which do lots of separate actions. Have separate usps and call each from code.
Reasons to use separate databases:
1) Unrelated data - Group data that is interrelated - andonce databases get beyond a certain complexity, look to separate out blocks of related data into separate databases in order to simplify.
2) Data that is of either higher importance (e.g. Personal Details) should be separated to allow for greater security measures: e.g. screening this data from developers
3) or lower importance (e.g. Logging Info) - this probably does not need backing up - and if it's particularly volumous, you probably don't want it increasing the time taken to back up the main site database.
4) Used by applications living on different servers at different locations. Quite obviously you want to site data as close as possible to the consuming application.
Without really knowing the size and scale of your system, difficult to give full opinion, if it's just your own site, one db may work for now - if it's commercial then i'd have 4 dbs from the word go: Membership details, Forum, Bug Tracker and MainSite related stuff.
Thus in code you would have a Membership manager which only talks to the Membership db, A BugManager, A ForumManager and anything else will only talk to the MainSite db. I can't think of any reason you'd need any of these databases talking to each other.
Just my inclination: although the three apps might not share much (not yet, anyway: but what happens when a forum post wants to reference a bug report?), they all belong to the same "system," so to speak.
I would definitely put all of the tables in just one database.
In my opinion , it is better to split the database for increased flexibility, security, efficiency, and scalability.
In future if there is any addition of requirement (you never know) which is common to all the three applications , it might be a little difficult to maintain.
For example: User login /audit trace for your 3 applications.
It may sound like I'm wandering a bit, but have you taken into account another possibility, that is separating all the authentication/membership functionality into an application itself?
From your description it seems you may add another application in the future. It would start to look like a network of sites, much like 37signals web apps, Google web apps or MSN web apps.
And thus, you may go for a kind of Single-Sign-On / Connect service. This one single application may offer authentication methods via web-services or any other mechanisms, it will have its own DB for you to tweak, modify, backup and move without affecting the other apps. I myself have found this situation many times and thus I love how easy is to share your Google or Facebook login among applications.
Perhaps I'm seeing it from a little higher perspective than yours, sorry if it's the case. If this is not an option, you may keep 4 databases: 1 for each application and 1 for the membership provider, which has its own connectionstring most of the time.
Of course it depends on the size of your applications' footprint on DB-level. 10 tables per app is OK, 150 tables per app would make the DB a little ugly to us, that being a personal preference.
Good luck with whatever option you choose.
The membership framework allows for partitioning across multiple applications, so you probably should have the following configuration:
Membership Database
Application 1 Database
Application 2 Database
Application 3 Database
Then, in each of the application databases, create synonyms that point to the membership database's tables for when you need to write your own queries that access both application data and membership data. Synonyms are easy to maintain and allow you change where the database is without changing any dependencies on those tables as the synonym names don't change.
Your application configuration in Web.config will determine how the data is partitioned in the membership database as you specify an ApplicationName that should be different for each app.
I have a situation where information about a user is stored in the web application cache and when that information is updated in one application - I want to notify the other applications (running on the same machine) that the data should be removed from it's cache so it can be refreshed. Basically I need to keep cached data in sync across multiple asp.net applications.
I have started down the path of using a central web service to help coordinate the notifcations but it is turning out to be more complex than I think it needs to be.
Is there a way that one asp.net application can easily reach across to another on the same box to clear an item from the cache?
Is there a better way to achieve shared cached information than using the application cache?
I really want to create a way for apps to communicate in a loosely coupled way - I looked at nservice bus but the dependency on MSMQ scared me away - my client has had bad experiences with MSMQ and does not want to support an app that requires it.
Suggestions?
Michael
I agree with Hogan. Best is to use a shared database. I want to add to that that, when using SQL Server, you can use SQL Cache Dependency. This SQL Server mechanism allows notifications to applications in such a way that used caches can be invalided directly after a change is made to the data.
A shared database is probably going to cause you the least pain.
Edit
Note: ASP.NET allows you to make "cache clearing" triggers on SQL server changes. Should be a quick search in the cache examples on MSDN to find some examples. Thus when the user info stored in the cache changes in the DB the local cache copy will clear and be re-loaded from the DB.
There are commercial distributed caches available for .net other than Microsoft Velocity - NCache, Coherence, etc.
How about Velocity? It's a distributed cache that works between servers as well as between applications. It has PowerShell management and all sorts of documentation to get you going faster and be far more maintainable in the long-term.
What about COM/DCOM, using namespace System.Runtime.Remoting
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.