Wow. That's a mouthfull. For db questions
you should check out the
jdbc forum. The cowpokes over there spend all their time messing around with db type stuff. However, most of your question doesn't have much to do with db details.
First of all, welcome to OO design. That's what you're dealing with here. Coming up with a good OO design tends to make the implementation fall out rather nicely. In some ways the design is the problem solving while the coding is just implementing the solution.
It sounds like you have a couple basic objects: Metals, Non-metals. The first question is why make these separate classes? Are there methods that one class can do that the other cannot? Let's say that we do want to make two separate classes (from a common parent is fine). Now, what should the classes contain in terms of properties (fields)?
Your first draft has this:
Since the "type" of the object is already determined by the class itself why do you have a type field too? Chances are real good that you don't need that field. The name is good but the other two fields need some help. Whenever you have a list of things it is best to use a data structure of some sort to hold that list rather than a string that you have to parse over and over again. How about using an array to hold the properties and an array for holding the weaknesses?
Now you might end up with something like:
I think that about covers the fields. You might consider using objects instead of chars for the individual properties and weaknesses. If the props or weaknesses are at all complex you might want to encapsulate that info. It will give you more flexibility in comparing properties to each other. But let's leave it simple for now.
The next issue to consider is comparing two Material objects. The comparison is supposed to find the common properties and union of all weaknesses. This comparison method should be implemented in the Materials class since you want to be able to compare any two Material objects. The comparison method will just use for loops to iterate through the properties and weaknesses arrays of the two objects in question and find the common elements.
After you have written the comparison method your main program becomes fairly straight-forward. You have a list of Metals and a list of Nonmetals. As you traverse the lists you hand each pair to the comparison method and display the results. I'm glossing over a lot of the details here because they depend a lot on how you implement your lists.
Now that I've kinda got you pointed in the right direction let me throw something else at you. Instead of using arrays to hold your properties and weaknesses in the Material class why not use a Set? For a single object there are no duplicate properties or weaknesses, right? So the Set concept seems to work. Each list of properties or weaknesses can be a Set. A very big advantage to doing it this way is you can now use set operations for your comparisons. The list of properties that two objects have in common is just the intersection of the objects' properties sets. The list of all shared weaknesses is the union of the objects' weaknesses sets. So now your comparison method becomes much simpler (and probably more efficient).
I know this is a long reply but it's really just scratching the surface in terms of OO design. Hopefully it gives you some stuff to think about and helps you get going in the right direction.
_M_