May 12, 2011 at 1:10 pm
Have you ever worked with ASP.NET?
If you can't answer my question then I'm not going to provide you with any additional information.
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 12, 2011 at 1:23 pm
@Dwayne Dibley
Thanks for the suggestion. That had been suggested at one point, but our network is managed by a contract company and I don't think we can ask them to do that unless we alter our contract.
@Welsh Corgi
Nothing is decided yet on the presentation layer, but we've talked about Silverlight, ASP .NET, and WinForms. The data access layer will most likely be WCF.
May 12, 2011 at 1:45 pm
You just can't say that you are only ever going to have one user for any application that you develop. That is a new approach to security that I have never heard of
You have to base your security model based on the Business Requirements and the Environment.
You may was to look into the ASP.NET Security Model and then you will understand my question.
As Tom pointed out, how can you state that you are going to essentially have a UserID Stamp on each record to uniquely identify each user when you only have one UserID for a Database? What algorithm are you going to use to derive this?
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 13, 2011 at 4:55 am
Welsh Corgi (5/12/2011)
As Tom pointed out, how can you state that you are going to essentially have a UserID Stamp on each record to uniquely identify each user when you only have one UserID for a Database? What algorithm are you going to use to derive this?
His amended verdsion of point 5 covered this - for any updates the app calls a sproc to do the updates, and one of the parameters of the sproc says which (NT) user the app is calling on behalf of; tis is stored in all records updated (every record has a "who updated me last field) and that means a history logging trigger also has the infomation (it's in the inserted table created automatically for any DML trigger).
I don't much like this (it's probably not the way I would do it - but I haven't seen the business requirement or the operational constraints so for all I know it may actually be the best way, so I can't say it's wrong), but it's certainly workable: and if the app has a "who can do what" structure in it is quite flexible. As long as the history logging doesn't blow performance (and that's really a matter of question of what throughput is required, and maybe also a question of mapping things to drives in a sensible manner if the throughput is high enough to need that).
Tom
May 13, 2011 at 6:38 am
Thanks for the input everyone!
I was also wondering what types of things you always do on your databases. Obviously things like normalization, clustered indexes, indexes, and smallest datatypes needed are almost always used, but what else? Maybe things you learned from bad setups?
May 13, 2011 at 7:14 am
SpectralGhost (5/13/2011)
I was also wondering what types of things you always do on your databases. Obviously things like normalization, clustered indexes, indexes, and smallest datatypes needed are almost always used, but what else? Maybe things you learned from bad setups?
Sounds like a homework assignment?:hehe:
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 13, 2011 at 8:42 am
Maybe this conversation is a little too broad for this thread. I'll start a new one for specific topics.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply