Roz Clarke
zora_db at yahoo.com
Thu Aug 25 05:30:02 CDT 2005
To tie this back to the dicussion about join tables (what I always called 'resolution' tables because they resolve a many to many relationship), entities in the system are linked to cases via an 'Involvements' table. This is like the idea of roles that Debbie mentioned. So there is a big ol' library of entities (people & organisations). There is a customisable lookup of standard capacities: Claimant, Defendant, Counsel etc. Entities are attached to cases by the 'involvement' which also gives the capacity in which they are involved; their role in the case. This is great, because it means that we get the advantages of having all our entities in one big table (reduces danger of duplication, which is a HUGE issue, makes finding individuals possible when you don't know what their role might have been, etc.), and we also get the advantages of categorisation; you can see what kinds of involvement individuals and organisations have had in your cases. If your search works well, and I like William's idea for dynamic filtering, there is no drawback to having everything jammed in together. Case's searches aren't great, but they are quick, and the users are perfectly happy, as Tom said. Another thing the system does that you may want to consider is allow you to set defaults, so that when you open a new case (indictment, for you) you can answer a couple of questions and it will then pre-populate not only involvements, but details and diary entries. The bit that doesn't work properly is attaching additional attributes to the involvements, and you'll want to make sure you can crack this; we can add custom details such as 'Defendant's vehicle registration' but we can't link them to a specific defendant involvement without jumping through a lot of hoops (especially as you might have several entities attached to a case all in the same capacity, multiple witnesses for example). I don't know if the same holds for you, but we are required by the Law Society to undertake conflict checks, which means that we *need* to know if our client has been the third party in another case. This is another thing Case doesn't do very well because the front end is badly implemented, but the table structure allows you to get the information out easily enough. --- Tom Bolton <tom.bolton at donnslaw.co.uk> wrote: > Right, although this *might* be simplifying a little. > > We (Roz and I) work for a big Law firm who use a software package called... > wait for it... Case. Conceptually, the basic object is a 'case', which will > have (amongst other things) the following: > > - Capacities > - Entities > - Details > - Activities > > It's best to think of the 'case' as the container for the capacities, > details etc. within. These are almost like properties and methods of a > class; come to think of it they probably are. > > Capacities are types of a person or persons, such as Claimant, Client, > Defendant, Police, Third-party Insurer etc. Entities are instances of those > capacities, i.e. an instance of the Defendant capacity could be Mr. Smith > who would be the entity. A bit like a UDT, capacities have several > associated properties (name, address etc.) Capacities can be linked to each > other (eg. Def. and Def. insurer) using an extremely convoluted method > called the 'acting for' which makes me shudder just thinking about it. > > Details are more basic 'properties'. Common ones we use are Claimant's > Vehicle Registration, Defendant's Policy Number etc. > > Activities can be thought of as Methods of a class, and will 'do' certain > things like produce a letter to Defendant's Solicitor. By the sounds of it, > these wouldn't be that important to you. > > Discussing this with Roz, she pointed out that having all the capacity types > in one big list has never phased our 200+ users who are at all points on the > spectrum in terms of computer literacy. Trust us, just bung 'em all in > together. Give each capacity a type, and leave it at that. > > To sum up, each 'case' has 'capacities' (people), 'details' (things), and > 'activities' (methods to perform tasks in your 'case'.) > > I've horrendously over-simplified a piece of software it's taken me 6 months > to find my way around so if none of it makes sense, please do ask! > > HTH in some small way > Tom > > > > > -----Original Message----- > From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] > Sent: 24-Aug-2005 19:16 > To: accessd at databaseadvisors.com > Subject: RE: [AccessD] Logic issue > > I think you need to have a 'people' table. Whether a person is a judge, > lawyer, defendant should be determined by relationships to the tables > relating to those designations. > > Drew > > > > The contents of this message and any attachments are the property of Donns Solicitors > and are intended for the confidential use of the named recipient only. They may be legally > privileged and should not be communicated to, or relied upon, by any other party without > our written consent. If you are not the addressee, please notify us immediately so that we > can make arrangements for its return. You should not show this e-mail to any person or > take copies as you may be committing a criminal or civil offence for which you may be > liable. The statement and opinions expressed in this e-mail message are those of the > writer, and do not necessarily represent that of Donns Solicitors. Although any files attached > to this e-mail will have been checked with virus protection software prior to transmission, > you should carry out your own virus check before opening any attachment. > Donns Solicitors does not accept any liability for any damage or loss which may be caused > by software viruses... > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com