Hi,

On Mon, Sep 16, 2013 at 9:33 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:

Yep, that was one of my ideas too. So, less work will be necessary on C4 subs.
But as said K. Fisher, if there are "deleted..." tables, it is probably for one reason??

Here are some pros and cons of keeping them in the same table, but with a deleted flag.

PROs

--------------

[1] Foreign key relationships can be expressed and enforced without contortions.

[2] Certain types of UNION queries would not required.

CONs

----------

[1] Most SQL queries would need the equivalent of a 'AND NOT deleted' clause tacked on to them.  Easier to do cleanly with DBIx::Class, perhaps, but that would still leave SQL reports (and legacy code).

[2] Code would have to ensure that you don't end up with active items attached to logically deleted bibs.

[3] There may be a point where a library or consortium that has been running Koha for a long time ends up with a significant portion of their biblio table containing logically deleted records, to the positive detriment of query performance. 

Not really a clear win either way.

With some reluctance, as it seems a bit messy, I guess I lean towards creating an aqorders.deletedbiblionumber column.

Regards,

Galen

-- 

Galen Charlton

Manager of Implementation

Equinox Software, Inc. / The Open Source Experts

email:  gmc@esilibrary.com

direct: +1 770-709-5581

cell:   +1 404-984-4366

skype:  gmcharlt

web:    http://www.esilibrary.com/

Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Université Rennes 2
Téléphone : 02 99 14 12 65
Courriel : mathieu.saby@univ-rennes2.fr