On Tuesday 03 October 2006 07:13, Ian Haywood wrote: > Horst Herb wrote: > > Now it performs just wonderfully even for complex nested multi-join > > tables > > You mean using the :include parameter?
Yes, for example. Made a huge difference. > Just on that, one problem I've run into is you can't use :include on > polymorphic joins. > viz I have a class Log which is polymorphically joined to Drug, Note, > Disease, etc. classes. I don't think this is a good design in any case. For simple logging, I'd use either the backend inherent methods (eg logging facilities in PosgreSQL >= 8.1) or ActiveRecord's built in logging - has to be much faster For *versioning* (as opposed to simple logging) I prefer to add a boolean field "deprecated" and an integer field "current" which points to the current version of this record (emulate a linked list - if you need even better performance for traversing versions both ways, emulate a double linked list where the current record stores a pointer to "previous"). There is also an integer field "version" which simply counts the number of versions so that you don't have to run a query to find out whether any one entry has older versions or not. Then you simply add a "before update" filter which - creates a new record with the contents of the update + increased version counter - reverses the update for the current record, but tags it as deprecated and adds the pointer to current Alternatively, you could use the model I used i gnumed - an extra versioning table for every table - but I find the proposal above better since there shouldn't be much versioning in medical records anyway (editing an already saved record should be a rare exception) and you want to keep version history in any case anyway Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
