Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

I have first experience of parallel programming of code which actively works with relational database. I find it interesting to combine .NET parallel programming primitives with database locks/transactions and I'm interested in articles on this topic. Could you please advice some (.NET is optional)?

share|improve this question
Your question is way too broad. A database engine is inherently concurrent and takes parallel requests. You are more likely to bollix the client code and cause race conditions on the database – gbn Feb 20 '11 at 11:22

1 Answer

up vote 1 down vote

Not answering your question but...

IMO that's a mistake, unfortunately you see this kind of thing more and more often where code getting intermingled with database which leads to maintainance and performance problems.

There are some instances where it might be warranted, like doing some quick-n-dirty small application where you run linq-2-sql.

However in general I'm a firm believer that having a layer of abstraction and separation between the database and the code. The programmer shouldn't need to know and worry much about the inner working of the database but have a set of stored procedures to work against. Having the correct set of sp's might be a point of cooperation though.

Likewise the database designer/programmer shouldn't need to worry about changing around fields, tables or optimizing performance in the database without having to worry breaking something the programmer has done directly against the database instead of a sp.

Not having a clear separation of layers in their architecture is one of the most common and most expensive mistake I see over and over done in big projects.

In your case, without knowing more, you should probably have the database deliver a dataset and work on it in parallel. Running concurrent queries against data that is not in-memory is typically not good performance anyways

share|improve this answer
2  
If you're not answering the OPs question, then you should maybe find a more suitable question for your answer? – Martin Wickman Feb 20 '11 at 12:25
Sometimes it's good to answer the question they should be asking "is this a good idea?" ;) – konrad Feb 20 '11 at 12:29
I have seen the stored procedures advice before, and it strikes me as the wrong place to separate things. A much better place for that abstraction layer is in the ORM the application uses, and not within the database. – btilly Feb 20 '11 at 14:25
1  
I realize that ORM vs SP's is largely a matter of taste and opinion. Nevertheless it strikes me as ORM's is programmers answers to prefer code over SQL (in the same regards as having "everything" in the database is DBA's answers to prefering SQL) and you get a dependency between the database and the ORM-layer. Also it makes it harder for the DBA and programmer to optimize separately since you have no abstraction between the two. – konrad Feb 20 '11 at 21:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.