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