When Near-Duplicate SDL Tridion Schemas Makes Sense

This question came up in a recent Content Modeling workshop. The customer was wondering why you'd want separate "Press Release" and "Article" schemas. Why not conslidate them into a single schema? Excellent question. Here's my view.

You'll often see nearly identical SDL Tridion schemas (content definition items--think "xsd" not "database") with fields like:

• heading
• subheading
• image
• description or summary
• repeatable paragraph or section, an embedded schema with the following:
• subheading
• body

An "article," "blog post," "press release," or even "biography" schema may have very similar or even the exact same fields. The inclination might be to consolidate these, which is okay sometimes. Here's where it makes sense to have similar, but distinct schemas.

1. More control over permissions -- separate schemas lets different sets of authors create only certain types of content.
2. Simplify page template logic -- separating schemas gives you better control over how content displays on a page.
3. Reduce template-selection options -- templates associate to schemas and authors only see the templates that relate to that schema. No need to show templates that authors won't use most of the time. This also impacts the Content Delivery API--imagine selecting all press releases... except these that really aren't press releases, but  are using the same schema. Authors would need a redundant "type" selection.
4. Simplify author experience -- fellow Tridionaut, Asier Fernández also prefers that schemas have only the fields that apply to a given scenario, content authors can get confused by unclear fields they should ignore in certain contexts.
5. Improve organization and default schema selections -- by setting linked schemas in folder properties, new components in that folder automatically have the right schema and fields. Authors don't even need to select New Multimedia Component if this is set to a specific Multimedia Schema.
6. Reduce broker database size (minor point) -- we get a dynamic component presentation per template x component. This isn't such a big deal IMO because this is a linear change (nx2 or x3 rather than n^2)
7. Flexibility and independent development -- changes affect all components. If you suspect some content will get different types of fields or keyword options, consider separate schemas.

You can optionally use the same embeddable schema to consolidate the actual fields, but still get the benefits from above. Use embeddables when:

• Your rich text and keyword options are the same across authors and content. Changes to the embeddable fields affect all schemas that use them. 
• You need to allow repetition for a set of fields.
• You want to use the same set of fields, but give the entire set a different description name.

Happy designing. I'd love to hear your thoughts on what's worked for you and how you approach schema design, feel free to leave a comment.