O que fazer direto no BD e o que fazer no C sharp?

Olá! e um assunto muito bom para ser discutido, eu mesmo já me perguntei isso, já conversei com uma pessoa que tem bastante experiencia em banco de dados (SQL SERVE) ele me falou que é bom deixar a responsabilidade no banco, e me foi sitado um exemplo: em caso de queda de energia a requisição e enviada ao banco que continua fazendo a consulta mesmo que o cliente caia, mas também já conversei com uma pessoa que e bastante experiente em desenvolvimento, e me disse que deixar tudo na aplicação e melhor de se dar manutenção futuramente, eu acho que existe casos e casos, cada empresa tem sua metodologia ou melhor cada equipe de desenvolvimento, mas e isso espero ter colaborado ^^

Exatamente, cada caso é um caso. Mas com relação à manutenção, depende muito do que será feito, pois veja só: supondo, como a Rachel falou, um trigger que faz o lançamento das vendas em um caixa (registra o total vendido, somando no total do caixa). Imagine que em algum tempo é necessário lançar esses movimentos também em outra tabela.
1) se estiver tudo em um trigger, basta atualizar o script no BD;
2) se estiver na aplicação, será preciso recompilar a aplicação toda (salvo alguns casos, como web);

Ou seja, no banco facilitou a manutenção. =)

Só muito cuidado com o uso excessivo de triggers. Acho elas um tanto preocupante. O usuário não tem controle sobre uma trigger. Elas são controladas pelo banco, através dos eventos em que elas estão ligadas. Para se dar manutenção em tabelas com triggers, é necessário desligar as triggers, fazer a manutenção e depois religá-las. Eu não gosto muito de triggers. Prefiro as Stored Procedures, mas é claro, são objetos diferentes, mas às vezes têm a mesma finalidade. Um insert eu prefiro uma SP e por serem pré compiladas, torna as operações envolvendo-as bem mais rápidas assim como as views. É só para pensar um pouco. Agora, regra de banco, pra mim, com algumas exceções, deve ser mantida no banco.

É... não há regra enão, né? Está sendo muito importante saber a opinião de todos vocês. Tenham certeza que estão me ajudando muito nos estudos e tomada de decisões.
Grata a todos.

Eu trabalhei em uma empresa em que o dono se recusava a utilizar triggers e procedures por dois motivos:
1) esconder a lógica da aplicação no aplicativo, pois o banco qualquer um pode acessar e ver suas fórmulas e etc;
2) é mais fácil encontrar um programador que fizesse tudo em Delphi (no caso dele) que um que manjasse bastante de programação no bd;

Concordo em parte com esse cara. Não pelo motivo de encontrar mais fácil programador de interfaces que de banco. O problema também está em aplicações multibanco. O uso de Triggers e SP é único para cada tipo de linguagem de banco. Por exemplo. Se você escreve suas triggers e sp's no T-Sql(Sql Server) e se por algum motivo ter que portar seu sistema para Oracle ou PostgreSql, terá que reescrever tudo novamente para essas linguagens. Quando se usa Entity ou N-Hibernate, esses caras já sabem o que fazer quando há mudanças de banco, mas o uso de triggers e sp, fica sem sentido, quando se usa esses frameworks. Eu optaria por usar N-Hibernate ou Entity, aí depende do projeto e conhecimento de cada programador. Se a aplicação vai usar vários bancos, eu fico com o N-Hibernate. Se ficar com Oracle e Sql Server apenas, aí pode ser o Entity(me disseram que ele só roda com esses dois bancos, nunca testei em Sybase, Firebird, Postgre e etc). É um estudo bem interessante, como disse um colega bem acima. Entre triggers e sp, eu prefiro as sp, mas minimizo ao máximo o uso desse recursos de banco. Se tiver que escolher, não usaria nenhum, a menos que minha aplicação for garantida que será usada em um único banco, o que não é conveniente para uma fábrica de software, por exemplo, que desenvolve para os mais variados ambientes, negócios e banco de dados. Estude e aplique.

Muito bem observado, PJava. Principalmente quando falou dos ORMs.
Aqui na empresa, um desenvolvedor opta por criar procedures para as operações de CRUD e utiliza-las em datasets tipados. Para gerar os procedures ele utiliza uma ferramenta chamada SSMS Tool Pack, muito útil por sinal.