Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
I'm working on putting pk on tables in the DB.
I've a few other suggestions to do :
The bibliosubject table has a no indexes. It would be useful,
imho, to put one on biblionumber, and one on subject, to speed up searches.
The problem is that subject is a text field (BLOB), so can't be indexed.
in the sample DB, there are only 3 record being more than 80car long. And
they are, (again imho) unuseable for searches : WORLD WAR, 1939-1945 - PRISONERS
AND PRISONS, GERMAN - PERSONAL NARRATIVES, NEW ZEALAND, for exampl. I had
divided such a subject in 3 or 4 subjects. Do you agree to modify column
type to car(80), and putting an index ?
The bibliosubtitle table has the same problem with the field
subtitle. It could be changed to car(255) without harm (only 4 records with
a subtitle bigger than 255 !)
The calatogueentry table : same problem as bibliosubtitle. Same
response ?
The borexp (expiration date) table seems to have a problem :
there should be only 1 record for 1 borrower (the pk should be on borrowernumber),
and for 2 dozens of borrowers, there are 2 records. Do you confirm it's a
bug in the datas ?
The borrowers table has the same problem : the 1000000624,1000001224
and 1000001225 are present twice (they are test borrowers ?). If they weren't,
I could put a pk on borrowernumber field. I can correct by deleting those
records.
The aqorderbreakdown and issues, and reserves
tables should have a pk, but due to trash in sample db, the alter table does'nt
work. Uncleanable by script (too many errors). I will
in a lot of tables there are columns that should be "not null" defined,
and that are not. I've corrected this to enable pk-ing.
Once I will have answers to those questions, the bd-patch will be released
very soon (script perl), and the admin tool will follow (i can't release
it immedialty, because pk is needed. But it's mostly writen)
--
Paul