What design patterns should I apply in application with database access

Make sure all your code is encapsulated in a data access layer. Code against interfaces so that if you need to write a new data access library, you don't have to change all calling code. This will at least isolate all data access into on library. How likely is the changing of database to be? Don't make the software complex for the what-ifs as this will just make life more difficult.

Abstract something 'on-fly' and only when You can clearly see a benefit.
Otherwise - that's just waste of time.

Do not think like:

I should use pattern [x] because it might fix [y]

Think like this:

Oh crap, again got to write same stuff. Let's see how we could avoid that...

There's a good design pattern called Data Access Object, you will have to incorporate it into C#.

Summary:

The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.