[OPEN-ILS-DEV] Monograph Parts

[Dan Wells]

Hello Mike,

At first glance I think this is a very welcome development, and I have a just a few comments.  First, I would advocate for some kind of a 'label_sortkey' on biblio.monograph_part.  Even if all it did was pad numbers, it would solve 95% of 'part' sorting problems.  Second, and perhaps this was already discarded as a simplification measure, but I think we should consider dropping the primary key on asset.copy_part_map.target_copy to allow for multiple parts per copy.  This would not only better reflect reality in certain cases, but I think it could also lay some groundwork for future bound-with functionality (put 'part's on your boundwith records (or let the map point to a part *or* a record), then sever the link from call_number to record).

Dan

-- 
*********************************************************************************
Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
Hekman Library at Calvin College
616.526.7133


>>> On 2/15/2011 at 3:09 PM, Mike Rylander <mrylander at gmail.com> wrote:
> I'll be starting work on an implementation of Monograph Parts (think:
> DIsks 1-3; Volume A-D; etc), well, right now, in a git branch that
> I'll push to http://git.esilibrary.com/?p=evergreen-equinox.git;a=summary 
> but I wanted to get the basic plan out there for comment.  So,
> attached you'll find a PDF outlining the plan.  Comments and feedback
> are welcome, but time for significant changes is slim.
> 
> This is not intended to cover every single possible use of the concept
> of Monograph Parts, but I believe it is a straight-forward design that
> offers a very good code-to-feature ratio and should be readily used by
> existing sites after upgrading to a version containing the code.