https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129
--- Comment #10 from David Cook <dc...@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #9) > This is really for multi branch sites that need more granularity. Minor > things like the default MARC organization code are defined globally and then > overridden with a new column in 'branches'. This pattern can be problematic > in my opinion, handling it on a per-case basis. > > And adding columns everywhere we want to make a syspref overridden > per-branch looks worse than NULL values. Those are good points. I've wondered a bit about branch_configurations, item_configurations, and patron_configurations, but then there are times when you need combinations of all 3, so having just one configurations table as you've done does make sense. Something about the configurations table *feels* wrong though. That said, maybe it's just my mind trying to prematurely optimize. I suppose even if you had 1000 library branches, so long as you indexed by branch, patron category, and item type... you could do a lookup pretty easily. So scale shouldn't be an issue. And having 1 big table versus smaller tables or configuration files makes it easier to add new configuration options (although possibly with a downtime cost at upgrade time for adding columns to all existing rows if you have a large configurations table but I doubt the configurations table would ever grow that large, and if it did then we could split it out more at that point). I suppose I can't think of any good reason not to do a "configurations" table. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/