Hi, On Mon, Sep 16, 2013 at 9:33 AM, Mathieu Saby <[email protected]>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: [email protected] 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
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
