"Static" is sometimes a naughty word in the C# world, because it makes it difficult to create Unit Tests around the class in question, unless the class is doing nothing but logic-processing and has no database, file I/O operations, or any such behavior. If you're passing data or commands from layer to layer, then I would suggest that your class NOT be static.
Did your friend specify WHY your data classes should be small? I suspect its not because of memory size, but rather because its best to break those data classes down to be as small and specific as you need, and not any larger. When you first get into OOP, there's a tendency to create "God" classes that have dozens of methods and fields. This feels "right" at first ("Oh look, I've got everything I need in one class/spot, great!") but it quickly bogs down into an unmaintainable mess.
A common pattern that I like to use is having my data transfer object (or POCOS, they have diff names) be very small and very dumb. Just structures really (but not the "struct" keyword, that's a whole 'nother ball of wax), with no methods or behavior of any sort. Having properties that do very basic null checking, string building, and/or aggregation on other fields of the same class is fine, but any bigger behavior goes elsewhere. The class that actually does work (database, file stuff) is a separate class with a bunch of methods that take these data transfer objects as params, or return them as results. This "data access provider" class won't have very many properties itself, and usually implements an interface (keyword: "interface" in C#) that I define that requires those methods.
The point of the interface is so my web apps or whatever can just call that class through the interface, and I can hot-swap in a different class that satisfies the interface that might just drop in dummy data, for testing purposes. You can't do that type of thing if the data access class is static.
Summary: If you truly want your data access class to ONLY behave in one way (actually trigger sql calls or file i/o and not be "mockable") then your data access class can be static, but I'd recommend against it. You'll be boxing yourself into a corner later, if you get into Unit/Integration Testing. (However, it wouldn't be terribly difficult to refactor at that point honestly)