Disk access, I mean I/O time, is another resource to worry about.
It's OK to worry about unneeded memory usage, having cellphones with 1 to 3 GB or RAM or computers with 4 - 8+ GB or RAM is no excuse to not do things in the most optimal possible way. But use a bit more RAM to avoid slow I/O, or to concentrate most of the I/O in specific parts of the game like at the start of the level, is a perfectly valid excuse and one used by games since the first day.
I don't know how your structures look but hundreds of items cannot be so RAM filling. I would bet that 999 of your items take less RAM that all the graphics assets and sounds needed at any given time to draw a scene frame.
My posture on this: worry about RAM when the times comes and not before. If you manage to fit your entire game, or at least a whole level and then move all the heavy I/O to the loading screens that connect levels, you save yourself of having to deal with things like different hard disk speeds, something else than your game doing I/O operations at the same time, etc.
About having each item graphics loading when the player access the item description page (if this is what you are planning): It doesn't sound so terrible to me, maybe we can have a loading wheel that only the players with slower hardware will see, yet no game I have played do this leading me to believe that the items description text or graphics assets aren't a worry for the developers of those games.
RPGs with battles that moves the player away from the exploration map: maybe there is an opportunity to place disk access here. We can make the transition animation a loading screen.
Just consider the following: if data is small enough, then no matters which path you follow in respect to avoid freezing the game enough for the player to notice, probably either load from disk or already having everything in RAM will just work when you test it, but if we add to the formula that now you have to write the code to make the loading possible, that probably involves to process the format used to represent your items in disk, we have increased the complexity of the project, potentially without needed it.
You always can work in an incremental way. Design how your items will be represented in memory is something you have to do with or without the on demand loading system, so, start by designing them. Start adding items by filling an array of instances of your items, if you observe the memory go beyond what you are willing to tolerate then it's time to start your on demand loading system. The advantage is that you didn't lose any time, as the structures designed will probably remain the same, just that now instances of them won't exists on memory all time.
Same goes for everything else like monsters stats and so on.