I am trying to stick to Single Responsibility Principle better, and I am getting issues grasping how you can structure the overall class design for interacting having a database. Inside a simplified version, I basically possess a database that contains:

Manufacturer <== Probes <==> ProbeSettings

A probe includes a manufacturer. A probe has 1 group of configurations. The attached objects are utilized all around the application, and to be honest, the present implementation is really a mess.

Presently, here is a general look at how communication and objects are implemented:

public class Manufacturer
{
  public int ID; // Primary key, auto-incrementing on insert
  public string Name;
}

public class Probe
{
  public int ID; // Primary key, auto-incrementing on insert
  public int ManufacturerID;
  public string Name;
  public int Elements;
}

public class ProbeSettings
{
  public int ProbeID; // Primary key, since it is unique.
  public int RandomSetting;
}

// This class is a mess...
public static class Database
{
  public static string ConnectionString;

  public static void InsertManufacturer(Manufacturer manuf); // ID would be ignored here, since it's auto-incrementing.
  public static void InsertProbe(Probe probe); // Again, ID generally ignored.
  public static void InsertProbeSettings(ProbeSettings probeSet);

  public static Manufacturer[] GetAllManufacturer();
  public static Probe[] GetProbesFromManufacturer(int manufacturerID);
  public static Probe[] GetProbesFromManufacturer(Manufacturer manuf);
}

I see many issues here.

  1. Database does way too much.
  2. These objects could be immutable when read really, the only real problem is after placing, I am unsure what ID these were designated, and also the placed object has become obsolete.
  3. Whenever a class must get information in the Database, I'd need to add another Get approach to handle a particular query.

I am really baffled here on which a proper implementation could be. My main idea for improvement is a few type of base interface for database objects, even though it might only help for card inserts...

public interface IDatabaseObject
{
    void Insert(Database db);
    bool Delete(Database db);
}

What's a great way to really implement this?

Well the very best solution to utilize DB while keeping SRP (or other type of sane pattern) is by using some type of ORM (for instance, NHibernate).

This will help you to use classes because they are, rather than by hand throwing them from/to DB.

For instance, with NH your classes look such as this:

public class Manufacturer
{
  public string Name { ... }
  public IList<Probe> Probes { ... }
}

public class Probe
{
  public string Name { ... }
  public int Elements { ... }
  public ProbeSettings Settings { ... }
}

public class ProbeSettings
{
  public int RandomSetting;
}

As you can see, you already don't need GetProbesFromManufacturer since just navigate the gathering within Manufacturer.

Also, ORM will manage object ids and saving for you personally. So that all that you'll want is going to be only a small , fixed quantity of general techniques like LoadById/LoadAll, which fit nicely right into a class SRP which is data access. You also would most likely require a class per each complex and configurable query towards the DB.

It may sound as if you are searching for an ORM. Since you are employed in C#, I'll assume you can get LinqToSQL included in the .Internet framework. Linq can perform what you are searching for so far as controlling your fundamental CRUD procedures. Similar projects, also worth looking at, are Castle ActiveRecord and NHibernate.