bumping the authorised_values.category column to 20 chars ?
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 mysql> describe authorised_values; +------------------+--------------+------+-----+--------- +----------------+ | Field | Type | Null | Key | Default | Extra | +------------------+--------------+------+-----+--------- +----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | category | varchar(10) | NO | MUL | | | <<<<<< | authorised_value | varchar(80) | NO | | | | | lib | varchar(80) | YES | | NULL | | | imageurl | varchar(200) | YES | | NULL | | +------------------+--------------+------+-----+--------- +----------------+ 5 rows in set (0.00 sec) Good idea or Bad idea ? Mason.
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
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 - ... thus, only "cataloguing" auth values lists would appear in marc_subfield_structure.pl only "acquisitions" auth values lists would appear in aqbudgets.pl (note to everyone : aqbudget coming soon, it's a part of new acq module) ... I feel we use auth values for a lot of things (and that's nice), and they start to be poorly readable for librarians how to do it (imo) : add the column set it to '' when needing to list the authvalues categories, display those with the needed module or no module specified. Thus we would be 100% compatible with previous versions, and librarians could upgrade their setup to have something more readable. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
Hi, On Thu, Nov 20, 2008 at 3:20 AM, Paul POULAIN <paul.poulain@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]
-- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
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@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
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@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@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@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
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@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@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@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
On 2008/11/21, at 8:05 AM, Ryan Higgins wrote:
I favor Galen's approach.
Yep, i think it will do the job just fine
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.
Ryan
Me too, and if you remove all the auth_value rows for a category, the category dissapears ;/ Currently the common categories are hardcoded to be displayed (Asort1/2, Bsort1/2 etc..) I'll put my hand up and add this mod to the end of my list of SAN-OP acqui work.
Hi, On Fri, Nov 21, 2008 at 10:39 PM, Mason James <mason.loves.sushi@gmail.com> wrote:
I'll put my hand up and add this mod to the end of my list of SAN-OP acqui work.
Thanks! Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
participants (5)
-
Galen Charlton -
Mason James -
Michael Hafen -
Paul POULAIN -
Ryan Higgins