Me and two other colleagues are trying to understand how to best design a program.  For example, I have an interface ISoda and multiple classes that implement that interface like Coke, Pepsi, DrPepper, etc....
My colleague is saying that it's best to put these items into a database like a key/value pair.  For example:
Key       |  Name
--------------------------------------
Coke      |  my.namespace.Coke, MyAssembly
Pepsi     |  my.namespace.Pepsi, MyAssembly
DrPepper  |  my.namespace.DrPepper, MyAssembly
... then have XML configuration files that map the input to the correct key, query the database for the key, then create the object.
I don't have any specific reasons, but I just feel that this is a bad design, but I don't know what to say or how to correctly argue against it.
My second colleague is suggesting that we micro-manage each of these classes.  So basically the input would go through a switch statement, something similiar to this:
ISoda soda;
switch (input)
{
   case "Coke":
      soda = new Coke();
      break;       
   case "Pepsi":
      soda = new Pepsi();
      break;
   case "DrPepper":
      soda = new DrPepper();
      break;
}
This seems a little better to me, but I still think there is a better way to do it.  I've been reading up on IoC containers the last few days and it seems like a good solution. However, I'm still very new to dependency injection and IoC containers, so I don't know how to correctly argue for it.  Or maybe I'm the wrong one and there's a better way to do it?  If so, can someone suggest a better method?
What kind of arguments can I bring to the table to convince my colleagues to try another method?  What are the pros/cons?  Why should we do it one way?  
Unfortunately, my colleagues are very resistant to change so I'm trying to figure out how I can convince them.