Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
rbuckton
Starting Member
4 Posts |
 Posted - 2004-06-21 : 12:01:30
|
| I would like to manage locking of rows and concurrency in a web-based application in a manner similar to a check-in/check-out style. Is it better to have NULLable fields in a table to store the current checkout information, or a seperate table. The NULL fields seem like the way to go however I have seen quite a bit of negative discussion regarding the use of null fields, but wasn't sure if duplicating the keys in a second table to track checkouts was a better design idea. Any thoughts? |
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 2004-06-21 : 12:47:17
|
| My 2 cents...I use nulls.....people say to never use nulls...mostly because you have to code for it...So ok, code for it....What would you put in a NOT NULL Date of Death column?Brett8-) |
 |
|
|
rbuckton
Starting Member
4 Posts |
Posted - 2004-06-21 : 13:31:54
|
| I have no trouble with nulls myself, and as far as coding for it my application tier is .NET/C#, so i have either DBNull testing or the System.Data.SqlTypes namespace which can help me handle nulls. In C# 2.0 i have Nullable<T>/type? to also handle null cases, so i'm not that concerned, it's more of a matter of how to maintain a clean design in the database. I'm likely to go for the null approach as this is in a many-to-many link table where the relationship is what has the concurrency locking symantic, and creating yet another link table just for the concurrency records seems like a waste of space and not a very normalized approach. |
|
|
|
|
|
|
pessimistic locking/concurrency in application