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

[Michael Hafen]

Sorry, I am not as familiar with the authorized values tables as I
thought.  From your message I understand that the category information
is in the same table with the values, which would not be proper
normalization.

I'll withdraw my previous comments then.

On Thu, 2008-11-20 at 14:05 -0500, Ryan Higgins wrote:
> 
> 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
-- 
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