From Koha Test Wiki MediaWiki MySQL Binary

Contents 1 Table name singular or plural ? 2 Table names include _ or no ? 3 Table names prefixed or no ? 4 should we call 'users of the libraries' members, patrons, borrowers or users ? 5 opac_news table is not only for opac news, but also for staff interface 6 The following tables requires a Primary key: 6.1 accountoffsets 6.2 aqorderdelivery 6.3 borrower_attributes 6.4 branches 6.5 branchtransfers 6.6 browser 6.7 deletedborrowers 6.8 import_biblios 6.9 import_record_matches 6.10 language_script_bidi 6.11 language_script_mapping 6.12 matcher_matchpoints 6.13 matchpoint_component_norms 6.14 message_queue 6.15 notifys 6.16 nozebra 6.17 old_issues 6.18 old_reserves 6.19 reserveconstraints 6.20 reserves 6.21 search_history 6.22 serialitems 6.23 sessions 6.24 statistics 6.25 stopwords 6.26 tmp_holdsqueue 6.27 user_permissions 6.28 virtualshelfcontents 7 Merge biblio and biblioitems 8 Rename categories to borrower_category 9 Primary key name (id, xxxid, xxxcode, xxxnumber) 10 Column name with a _ 11 Tinyint(1) changed to BOOLEAN 12 Update letters table to have a primary key instead of a constructed PK 13 accountlines.accountno should be a foreign key for accountoffsets.accountno 14 the table need_merge_authorities could be removed and replaced by a column in authority table 15 Unused tables 16 Unused columns

Table name singular or plural ?

colinC: If using DBIx::Class and possibly other db orms the orm generates a consistent singular name for each object
(PP) copy of what was written on coding_guidelines page:

   * table in singular [+] or plural [+++++] form ? 
 //Tables in the plural make for some odd sounding code once you start using an ORM. 
 It sounds more logical to say $borr = Borrower->new(); than $borr = Borrowers->new(); We should be thinking about this in terms of moving toward a more 
 Class based concept (DBIx::Class) than in the handcrafted SQL of old. The main thing is to be consistent.
 Conversely, having a Borrowers class sounds better than having a Borrower class.  It's marginal as long as consistent.//

(PP) singular, for the same reason as ColinC & the one who wrote ("It sounds more logical to say $borr = Borrower->new(); than $borr = Borrowers->new();")

Table names include _ or no ?

Table names prefixed or no ?

should we call 'users of the libraries' members, patrons, borrowers or users ?

(PP) copy of what was written on coding_guidelines page:

   * Should we use patron [++], member [], borrowers [] ? (This question is nonsense because they mean different things: members and borrowers are subsets of patrons.)

PP: my preference would to to patron or user

opac_news table is not only for opac news, but also for staff interface

The following tables requires a Primary key:

accountoffsets

aqorderdelivery

borrower_attributes

branches

branchtransfers

browser

deletedborrowers

import_biblios

import_record_matches

language_script_bidi

language_script_mapping

matcher_matchpoints

matchpoint_component_norms

message_queue

notifys

kf: araik this table is no longer used and could be removed along with other code related to this feature.

nozebra

PP => this table is deprecated, it's OK

old_issues

old_reserves

reserveconstraints

reserves

search_history

serialitems

sessions

PP => this table has a UNIQUE KEY `id`, we should move to PRIMARY KEY

statistics

stopwords

tmp_holdsqueue

user_permissions

virtualshelfcontents

Merge biblio and biblioitems

Rename categories to borrower_category

Primary key name (id, xxxid, xxxcode, xxxnumber)

Column name with a _

Tinyint(1) changed to BOOLEAN

PP: Is there a BOOLEAN type in standard SQL ? marcelr: Would not recommend that. BOOL is an alias for tinyint(1); so that does not make a difference. Also i remember that there are/were some problems with boolean fields in MySQL.

Update letters table to have a primary key instead of a constructed PK

accountlines.accountno should be a foreign key for accountoffsets.accountno

the table need_merge_authorities could be removed and replaced by a column in authority table

marcelr: Is in use only when pref dontmerge==Do not update automatically. Most libraries will update automatically and will not use this table (and leave it empty). The current construction preserves space.

Unused tables

kf: following tables seem to be no longer used and are probably candidates for deletion:

• notifys
• ethnicity
• printers

Unused columns

kf: following columns seem to be no longer used and are probably candidates for deletion:

• borrowers.ethnotes / deletedborrowers.ethnotes
• borrowers.ethnicity / deletedborrowers.ethnicity