CiviCRM Community Forums (archive)

I have a question about how to go about adding some new basic data types to CiviCRM to support my particular need ...

I'm using CiviCRM to manage the information of a children's choir (members, donors, mailings, etc), and it's been absolutely wonderful.

I've been searching for an application to manage and access the catalog of holdings of the choir's music library, and I need a solution that satisfies these requirements: web-based, open source (or extremely inexpensive), not CPU-intensive (the more cycles we use, the more we pay our hosting company), and integrated with our existing systems (to prevent data inconsistency and to keep me from having to train people on multiple systems).

I believe that CiviCRM has the right elements to support my data model - composers can be modeled as individual contacts; publishers, distributors, and performers are organization contacts, etc. But I don't see how to model two other basic object types in the given framework - works and holdings.

A work is an abstraction of a piece of music, whereas a holding is a specific instance of that piece of music in the library. (Compare the metadata of a book in a library's card catalog vs. the actual instance of the book on the shelf.)

The basic need is that our Artistic Director needs the ability to search the database by composer, by voicing/instrumentation, or by category (Christmas, patriotic, wedding, etc ...). This means searching by fields in existing types (contacts), fields in new types (works), as well as tags applied to the new types (tagging works by holiday or tempo, for instance).

The existing relationship system seems like it would completely serve my needs - a Work is created by a Composer (created-by/creator-of relationship), a Work exists in the library as a Holding (if we've bought copies of it ... it could just exist as a work in a publisher's catalog and have no holding record if we haven't purchased any yet), etc. Adding custom attributes associated with the relationships would also serve my purpose (if a Work is published by a Publisher (org contact), then the publisher's item number would be stored in that relationship).

My question is this: how difficult is it to add new types to CiviCRM? I assume I will need at least two new tables (holdings and works), plus extension of the relationship system to recognize these new types, plus potential extension of the tagging system or creation of a new tagging system (can any object be tagged in the current system? Or only contacts?), plus new screens, searches, and reports. Is this right? Do I need more than this?

How does the extension of CiviCRM to this particular application compare to some of the other extensions (such as CiviCase or CiviSchool or CiviCampaign)? I'm not familiar with the implementation details of those components to be able to compare.

I'm up to the challenge of coding this myself ... I'm just looking for some guidance to make that effort more expedient.

Thanks for any insight you can provide.

-eP

I was just about to give the same reply.

I can't say with certainly how "how difficult is it to add new types to CiviCRM" but I don't think it will be easy.

However Drupal is meant for this type of thing and adding content types and taxonomy and relationships is something Drupal does well, and there are lots of tools out there to assist with various aspects of this.

Not to mention that a CiviCRM-based solution will have little or no audience (most probably) and therefore little or no chance of being included in future releases and maintained etc...