December 30, 2008 at 2:27 am
Hi, All
I want all of you to contribute in brain storm, about the best practices to be addressed while developing, installing, and the whole life time of an intranet web based application, in regard to the connection strings, credentials, encryptions extra...
Ur contributions are highly appreciated and nedded...
December 30, 2008 at 3:00 am
This is a SQL Server forum, your question about best practices for developing an application might get better answers in an applications related one.
In regards to the application backend -providing you are considering SQL Server as your RDBMS of choice - there are no differences in between planning for an Intranet or any other kind of application. You may want to check if your backend would be OLTP or DSS alike then just do your data modeling taking into account your findings.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.December 30, 2008 at 6:28 am
Hello,
ok thx
December 30, 2008 at 9:24 am
PaulB (12/30/2008)
...there are no differences in between planning for an Intranet or any other kind of application...
Whlie this would be true for your data modeling and schema design, it probably won't be true for things like planning your SQL Server security, logins, and users.
There is a good chance in a web environment like an intranet/internet, that you will want to only have a few limmited number of SQL Server logins, such as: administrative user, standard user, readonly user. This would allow you to manage resources more effectively on the web server by setting up fewwer connection pools that are larger. If you were using windows authentication or had individual SQL Server logins for each user, then each user would have a different connection string and would prevent connection pooling.
The reason connection pooling can become important in a web environmnet is that creating new database connections from the web server to the database can easily take longer than the actual query or operation being performed by the web page. Connection pooling keeps a number of connections open between the 2 servers, so that when a new connection is requested by the application, it will use an already "open" connection from the pool that's not being used, reducing the time it takes to do the initial server resolution and authentication.
December 30, 2008 at 11:34 am
Chris Harshman (12/30/2008)... you will want to only have a few limmited number of SQL Server logins, such as: administrative user, standard user, readonly user.
I can see your organization has very flexible security policies, no way in hell we can even dream of doing something like that.
Well... because there are different tastes God created different flavours, isn't it? 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.December 30, 2008 at 2:54 pm
PaulB (12/30/2008)
I can see your organization has very flexible security policies
Well, we have to maintain and enforce security within our applications, instead of relying on Active Directory / Windows Authentication to dictate to the application what a users security should be.
December 30, 2008 at 9:54 pm
Well, are u saying that i have to have more than one connection string in my web.config, each on which will have its own credentials!!??
December 31, 2008 at 7:30 am
Well, I'm just a little bit of a .Net person, mostly a database person, but in simplest terms, yes, each different SQL Server login user would require a different connection string in ADO, and different connection strings require a different connection pool. Also you want to limit the number of connection pools to just a few on your web server to best utilize resources, having a separate connection pool for each individual user of the web application doesn't really make sense.
December 31, 2008 at 9:48 am
Chris Harshman (12/30/2008)Well, we have to maintain and enforce security within our applications, instead of relying on Active Directory / Windows Authentication to dictate to the application what a users security should be.
Nice. I'm pretty sure your SOX auditors are loving it, isn't it?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.January 1, 2009 at 9:46 am
Check out this article on msdn for a discussion of connection options for a web server connecting to a database server.
Steve G.
January 2, 2009 at 6:36 am
PaulB (12/31/2008)
Nice. I'm pretty sure your SOX auditors are loving it, isn't it?
Well, as I've stated previously I'm not really a .Net person, more a database person, so I'm just saying what the company I'm at now (private by the way so no Sarbanes Oxley) and previous companies even ones that were public, have done. I'm not saying there isn't a better way to do it, but Microsoft sure makes it difficult to do any other way.
January 2, 2009 at 7:26 am
Chris Harshman (1/2/2009)
PaulB (12/31/2008)
Nice. I'm pretty sure your SOX auditors are loving it, isn't it?Well, as I've stated previously I'm not really a .Net person, more a database person, so I'm just saying what the company I'm at now (private by the way so no Sarbanes Oxley) and previous companies even ones that were public, have done. I'm not saying there isn't a better way to do it, but Microsoft sure makes it difficult to do any other way.
Understood, it makes sense but, it doesn't mean the practice should be considered "best practice" as original poster has asked. Am I correct?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.January 4, 2009 at 7:51 pm
PaulB (1/2/2009)
Understood, it makes sense but, it doesn't mean the practice should be considered "best practice" as original poster has asked. Am I correct?
If you have some actual information to give to the original poster then please share. If all you are going to do is harass me for trying to help, well I'm not sure what you will actually accomplish. The point I've tried to make is that you need to ensure proper use of connection pools, to speed database access while controlling resource usage on the web server. Many places have done that by using a few select logins between the web server and database, and build the actual security into the application layers. There's nothing wrong or false about anything I've said.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply