use a custom db table, or use resources+TVs+FC+getResources?

I feel like I’ve solicited opinions on this before, but I need a refresher course.

When working on sites that need to manage (query & display on the front end, CRUD on the back end) simple records, with less than a dozen fields, and without complex joins or other data relationships...

Is it acceptable to just create a custom template & TVs for the fields, and (optionally) use Form Customization to enhance the user-friendliness of editing these records... and just use getResources with a customized tplChunk for displaying them on pages?

Or is this really bad form? Should resources never be used for records that are not intended to stand alone as web pages? Is it a hack to do so? Or is it merely a practical solution within a very flexible CMF?

Interested in all feedback & opinions. Performance issues, best-practice philosophies, ease-of-maintenance concerns, and the git-r-done factor are all relevant discussion points.

I guess I’ll use this as an opportunity to reiterate my philosophy in this area. MODX Resources are not intended to represent reusable content and/or data; they are for presenting unique views or services that can make use of reusable content and/or data.

Template Variables are IMO best used for organizing layout and presentation, not for storing data that you need to sort and search on. If your searching and sorting requirements are minimal, you can certainly get away with representing reusable content as a Resource; I would not say Resources should never be used in this way. But when scalability and performance are considerations, you are always going to be better off storing your data in a proper normalized fashion, using MODX Resources to access, search, sort, present, and/or manage that data as needed. MODX is optimized for creating layouts and abstracting logic from presentation. Using it’s generic structures to represent complex data relationships that need to be traversed in various ways will never be optimal.

Thanks for the concise summary. Makes a ton of sense.

Monday Morning follow-up question: What, if any, bearing does the concept of "Content Elements" have on this discussion? From the Revo Roadmap (3.0 section):

• Add Content Element support - Eliminates Resource Fields and makes Resources with an adjustable field base

Even if it has no direct bearing on this discussion, I’d love to hear a bit of embellishment on what the concept of Content Elements looks like in the minds of the core team.

Quote from: jrotering at May 23, 2011, 11:13 AM

Monday Morning follow-up question: What, if any, bearing does the concept of "Content Elements" have on this discussion? From the Revo Roadmap (3.0 section):

• Add Content Element support - Eliminates Resource Fields and makes Resources with an adjustable field base

Even if it has no direct bearing on this discussion, I’d love to hear a bit of embellishment on what the concept of Content Elements looks like in the minds of the core team.

Basically, the idea is that moving forward, all Content will be stored in Elements where it can be versioned, localized, and identified as a specific type of content. This is in contrast to the current mix of localizable Resource fields (content, pagetitle, longtitle, description, etc.) and Elements (TVs, Chunks, Snippets, etc.) which are combined to produce the Resource output. This way we have a central place to manage all Content and variations of it. For the users, this will also enable what amount to "global" Template Variables which can be assigned directly to a Resource without the Template relationship, either in an ad hoc fashion or using some kind of "set" of pre-defined Elements. This means no Content will be in the site_content (modResource) table, reducing it to storage of metadata only.

I’ll start with that and talk more about it if you have additional questions.