There are many legal
extranet systems in the marketplace which provide nice web-facing interfaces but are linked to back-end databases which are known as "flat-file" databases. Or there are others which are third party products which are commonly deployed in the legal environments, but some of these lock users into specific templates or interfaces being that they are packaged software solutions.
These types of databases are acceptable in some cases, but when attempting to process large volumes of data and documents or in cases where a user wants a particular type of configuration or application developed, they can tend to be problematic or, even worse, unable to meet the business requirements of a particular business situation.
This is because (without getting too technical) the best commercially available database packages are relational database packages (
click here for a definition of that term) which organizes data into tables with rows/columns with the ability to add relationships between the objects, referential integrity constraints, indexes, and the like. These databases also often offer the ability to actually store documents within the database (as opposed to the alternative of storing all documents on a file server directory and attempting to link to them from the database - relaying on data retrievals from multiple sources which tend to be problematic and slower). And, with some customized code in a layer on top of these powerful relational databases, you have now have the type of product which can be customized to meet the diverse needs of the legal community on a wide variety of situations and case management needs.
So, if you have a large quantity of data to be stored, be sure to ask what the system backbone technologies are, how flexible the proposed solution is, and be sure you can see a working version of an proposed implementation with the level of required complexity and at least double the approximate volume of data and documents you expect to store in your implementation. Be sure you do not accept a "standard issue" demo where only a few records are stored, a mere 5-10 fields are shown on the applications screens and the demo therefore responds with lightning quick speed. It is unlikely your end-state application will be that simple, so you need to be sure your demo replicates, as closely as possible, what your users will require.
