I'm writing a basic crud app that will be a combination of simple structured data and some narrative text. I'm wondering if the following is a good idea for a design concept, and if it's widely used. Say I have a Widget and a ThngAMaBob class, and each has a description field. would it make sense to encapsulate the text like so:
The markdown text would be the main type that the user would enter and edit. On a save, a markdown parser would create the html text, and a function would create a third text field that would strip out all the html tags, and that plain text would be used for searching.
The advantage to doing it this way, is that I could search just the TextElement table and return any obj associated with it, as opposed to searching each and every obj that contained a text field.
I've done that for complex text entities which can belong to a variety of objects in my design. For example a Taxon and a TaxonomicUnit and a ChecklistEntry and several other types can all have a Description. There's also an implied requirement that a Description can only belong to one entity.
The downside of that is that it isn't possible to determine what entity a Description belongs to, and I don't think you can use a standard entity-relationship diagram to describe my design. However I'm not using Hibernate or any other ORM system so I haven't had to struggle with them.