Just wanted to echo some of Jono's comments. Aperture will let you manage things pretty much to whatever your needs.
As Jack does, I create a new folder from a shoot. I dump all the RAW images from that particular outing into that folder. I then rename those files, by simply adding a date prefix to them, retaining the original camera naming convention (e.g., _X5Dxxxx.cr2 for shots from my 1DsMkII, or _L100xxxx.dng from a Leica M8, etc.). So the new files become 072708_X5Dxxxx.cr2, as an example from a July 27, 2008 shoot. That name stays with all files, regardless of what I do with them. Any that get processed, get another letter added to the end (p for PS, a for Aperture, C for C1, etc.), and print files get a "size" associated also. So a file processed in PS to a 11x14 size for printing would become 072708_X5Dxxxxp11.psd, or if done also in C1 it would become 072708_X5Dxxxxc11.tif as an example. (I keep the size telegraphic...4 for 4x6, 5 for 5x7, 8 for 8x10, etc., or if odd sized, use that size, such as 8x12, 22x26, etc.) All of those files stay in the original folder with the RAW files, so they never get separated. The naming allows me to know which have been processed, and even by which method and to what printing size. All of those also get referenced in Aperture, so that they can be arranged in whatever folder or sorting structure I want. The utility here is that Aperture allows me to place things into whatever folder structure is convenient, such as Jono's "Scarecrows" smart folder, or whatever, but I can still go back to the the original folder to retrieve RAW or processed images to use any other way I want.
The concept of stacks applies nicely here also. I can keep the RAW and any versions of that image in a single stack in Aperture, so I may have 3-4 sizes, B/W, Viveza, different crops, etc., all in the same stack. As long as you keep the links back to the originals intact, you can work on new versions of things in Aperture, saving them back to the Aperture Library, or exporting those versions out to whatever folder or place you want, including back to their original folder (recommended). That keeps all files and versions of things processed differently or sized for printing all in one place. So if you need to pull up a file, make a print, or create a Web gallery from something other than Aperture, for example, all of the files are easily accessible. With the coding, you can do simple searches on file type, or even wild card searches for specific processing or sizes if you wanted. Very flexible. Things stay managed in Aperture, but are completely organized in their original folder for access/use by other apps as needed.
One of the main reasons I have kept this structure from the very start, was that I did use Bridge and ACR/PS for a ton of my event stuff, and still do. I can access the files from Bridge by simply pointing to the original folder, no matter where it is, or from C1 the same way. The use of ratings and color codes help in sorting there. I have been able to find files very quickly, and know how they have been handled just by the file name. Nothing ever gets lost or misplaced, and by having things referenced in Aperture, I am able to take advantage of all the DAM and other offerings, but still not lose my original file structure. If having separate special folders is needed, that can always be done, but I still keep things with the originals as much as possible. The only exception is for client prints from an event. I keep a separate Prints folder that has each client in a sub-folder and all print versions for each client get copied there. (I started this practice to allow easier access and retrieval or images for clients, and also to permit easier use with a RIP. The RIP opens the Prints folder and I just cruise down to the client name and select images for printing or reprinting.) That Prints folder can get pretty big, but it is an independent file of all prints made for all clients, kept mostly as a business disaster recovery tool, and stored on an external FW drive to be accessed by any computer as needed.
It sounds complicated, but in reality, it is quite simple and very flexible.
LJ