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 > <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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@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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
