Sorry for posting a binary attachment to the list, but it is small. Here is a draft database schema for discussion. For some applications, such as OpenOffice.org, the database can probably be accessed directly. For other applications that use an SQL database with their own defined schema, it can be accessed through SQL views, rules and triggers; for example, the accounting program SQL-Ledger. For applications that don't use SQL at all, we need a library that can import and export from the database (I have already written one that does this for GnoTime, the GNOME Time Tracker, which I will be packaging for Debian-Lex). The idea is that "Contact" will be a field that will store information about people, and people can be clients, fee-earner lawyers, opposing party lawyers, representatives of clients (eg. a corporate client that might have a director or similar representative), people who refer clients, or persons to be raised on a conflict-of-interest check. Another design feature of this schema is that not only each client can have more than one matter (or file), but that each matter can have more than one client. This database won't hold accounting information directly, eg. how much the client has on trust, this will be held in specialised tables in the accounting program (eg. SQL-Ledger). However, I have included credit card information here, maybe I should take it out. There are bound to be things I'm missing from here. -- JEREMY MALCOLM <Jeremy@Malcolm.id.au> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger.
Attachment:
debian-lex-db.pdf
Description: Adobe PDF document
Attachment:
signature.asc
Description: This is a digitally signed message part