[Koha-devel] bumping the authorised_values.category column to 20 chars ?

[Ryan Higgins]

I favor Galen's approach.  I've always found the interface confusing
for adding a new auth_val category: you have to enter the category's
first authorised_value at the same time you create the category.  This
is an artifact of the table design.   While it adds a small bit of
complexity
short term to db queries, if we adopt an abstraction layer, the joins will
be handled for us, so that complexity will go away.
'Proper' normalization, in this case, would involve creating the new table,
as doing so would decrease data redundancy.

Ryan


On Thu, Nov 20, 2008 at 10:31 AM, Michael Hafen <mdhafen at tech.washk12.org>wrote:

> Hi,
>
> I'm going to disagree with Galen here.
>
> I prefer to expand an existing table rather than add another when
> possible.  This is because more tables adds to the complexity of the
> database and the code.  With your suggestion there would have to be
> added left joins to a lot of authority code, where otherwise it would be
> adding columns to the select or the where clauses.
>
> It would make sense to add a table for authorized value categories if a
> category could be in multiple modules, or have multiple descriptions.
> The latter obviously isn't likely.  There is the possibility of a
> category being in multiple modules, but I think this is handled
> effectively by Paul's idea of having the module default to blank.
>
> Unless I'm mistaken proper Database Normalization would have a table
> where there is a 'has-a' relation, but not where there is a 'is-a'
> relation.  In this case I would say that a category is in a module, and
> so there shouldn't be a separate table to define this value.  Please
> correct me if I am wrong about this.
>
> Anyway, that my 2 bits.
>
> On Thu, 2008-11-20 at 07:51 -0500, Galen Charlton wrote:
> > Hi,
> >
> > On Thu, Nov 20, 2008 at 3:20 AM, Paul POULAIN <paul.poulain at free.fr>
> wrote:
> > > Mason James a écrit :
> > >> Hi folks
> > >>
> > >> Any objections to bumping the authorised_values.category column to
> > >> say.. 20 chars??
> > >>
> > >> I'm having to make my new auth categories a little terse/cryptic
> > >> because of the current 10 char limit
> >
> > No objection, but note that
> > borrower_attribute_types.authorised_value_category would also have to
> > be expanded.  To modify the suggestion slightly, how about keeping the
> > current length of authorised_value.category and creating a new
> > authorised_value_categories table:
> >
> > CREATE table authorised_value_categories (
> >   category varchar(10) NOT NULL,
> >   description varchar(80),
> >   module varchar(10),
> >   PRIMARY KEY (category),
> >   KEY module_idx (module)
> > );
> >
> > This gives us a longer description, and we can make
> > authorised_value.category a foreign key.  The module column would be
> > used to implement Paul's idea.
> >
> > > I think it's a good idea.
> > > Another idea I have would be to add a "module" field, to separate the
> > > different uses of auth values :
> > > - cataloguing
> > > - acquisitions
> > > - members
> > [snip]
> >
> --
> Michael Hafen
> Systems Analyst and Programmer
> Washington County School District
> Utah, USA
>
> for Koha checkout
> http://koha-dev.washk12.org
> or
> git://koha-dev.washk12.org/koha
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>



-- 
Ryan Higgins

LibLime  *  Open-Source Solutions for Libraries
Featuring KohaZOOM ILS
888-564-2457  x704
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20081120/83aa31eb/attachment-0003.htm>