http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4888 --- Comment #13 from Salva Zaragoza Rubio <salva@masmedios.com> 2011-04-08 19:49:18 UTC --- (In reply to comment #12)
I have a design problem with this patch. * marc_indicators marc_indicators_value => couldn't those table just be a field on marc_tag_structure ? * marc_indicators_values => this table sounds useless for me, it's a constant table, why not use a Perl array ?
Something like 2 fields: default_indicator1 enum('','0','1','2','3','4','5','6','7','8','9','a','b','c','d'...'z'); default_indicator2 enum('','0','1','2','3','4','5','6','7','8','9','a','b','c','d'...'z');
in marc_tag_structure are they not doing the same thing ?
Otherwise, I like the idea & like the fact you can have control over the valid values of indicators (even if, but i'm not a librarian), I still think most indicators are just here for cutting hairs in 4 -frenchism suspected-)
If we create the values of the indicators as a column in the marc_tag_structure then we can only set one value for indicator-field-framework, and we want to be able to set a list of values for indicator-field-framework. So I created a table "marc_indicators" to relate the field and framework with an indicator, and a second table "marc_indicators_value" related with the former to set a list of values, not only one. A third table "marc_indicators_desc" exists to specify the description of the value (related to an indicator-field-framework) on the language you want to. The table "marc_indicators_values" contains the allowed values for the indicators so the database is coherent and consistent and can check constraints and perform "on delete cascade" by itself. Besides this approach is more flexible so in a future a development in the intranet can be made to add more values without changing the database (the enum column). -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.