You seem to be confusing the concept of classes and data. If you can make the assumption in your vector-based implementation that the data you care about always contains 7 identical elements (or that it is acceptable for some properties to be "null" values) then you only need a single class that can be duplicated to hold any number of items you wish. In fact, if the assumption holds that any item has the same set of properties associated with it (Name, HP buffs, MP buffs, etc) then a a vector of such classes is a reasonable solution. Since you probably don't want to hard-code 500 items into the source code, you can use a simple file format to contain all item definitions and load them in when the game starts (presuming you actually need/want to keep the whole database in memory). You could use a spreadsheet program to create the file and save it to an easy-to-read format like .CSV, which is simply a textual list of values where each property is separated by a comma and each item is separated by a newline character -- super easy to read. If you don't have a spreadsheet program like Microsoft Excell, there are many free ones available (OpenOffice.org) or even free online ones like Google's -- you don't even have to install anything. Heck, its deadly simple to even create a CSV file in any text editor even.

Other format possibilites include XML, YAML, JSON, or any custom format you design yourself. Heck, you could even use an actuall embedded database like SQLlite -- many games these days use SQLlite for lots of things -- not just item inventory but for all kinds of data like NPC/Baddie stats, dialogue, sound effects and even saved games.

For runtime-storage, I might recommend something other than a basic vector though, just to optimize lookup performance. You might consider a hash map, a set, a sorted vector or binary tree or trie structure, and using the name as the key/lookup value (presuming names are globally unique).

Now, if items can have wildly-varied and arbitrary properties, then things become interesting. Then you would probably want something like a std::map where the key is the item name, and the "value" is another std::map -- in this second map the key value might then be the property name, and the value is some numeric type (probably double if both integer and floating point values are possible) assuming numeric data is sufficient -- otherwise it could be something like Boost's Any type.

There are other ways of organizing things, of course, but if you need more complexity than I've described here you're probably best off using SQLlite or some other embedded database.