The Drupal community goes with MPD's answer, mostly: CCK, with Views.
Personally, I hardly ever find that a good solution. The only place where IMO Views and CCK offer a real benefit in time and effort, is when the end-result is poorly or loosely defined. If, however, you have wireframes, mockups or designs to work to, views+cck will require a lot of undoing.
Another important consideration is Drupals lack of deployment. Too often, you create CCK+views, and throw a sauce of theming and some custom (form alter) code over it.
The chance then has an ugly deployment: without the new configuration (e.g. that new CCK field you defined) your theme breaks. But without the new theme, your new CCK-field breaks. In Drupal that is often "solved" with some downtime, during witch new code is rolled out and immediately followed by manually reconfiguring these fields. Though there are some complex "solutions" to this in the form of strongarm or features.
All in all, you will end up with CCK, Views, a bucketload of CCK fields-modules, VIEW addons and lots of gluecode. In the theme side, you end up with large and Div-infected overrides.
While all this was possible in a simple, clean, maintainable and highly optimised custom module with a single optimised and clean module.
It all comes down to how at home you feel with code. I, personally, don't mind cranking out a few lines of (clean, well architectured) PHP; others prefer to steer away from coding and prefer clicking around (though, In my experience they end up coding against more complex interfaces in the end, anyway)