Hello Al,

A saw that video for the first time some years ago. Very funny.

A couple of weeks ago I saw a Mongo DB demonstration. It looked like a very interesting and mature product.

My question to you is, Is it still a relevant video? You know enterprises that use it and are not satisfied with it? What are the major problems?

>In-line comments below.
>
>>HI all,
>>
>>I have been going through meetings with a client as they work through a radical redesign of their app. I am having a hard time getting them to understand some principles of good design. Their system is both a database (VFP currently) that is linked to a documents repository (through its RESTapi). The problem comes when they talk about copying documents between "files" etc. when really they should be storing a link to the document. They want to redesign completely how their screens work together.
>>
>>Before I get even more wordy, the current design is that they have a plaintiff table and each plaintiff can have multiple "files" e.g. for a single car accident, they might have a file open for benefits they receive from their car insurer and they might have a 2nd file open for a tort action against the person driving the other car. In short, the structure is one to many between Plaintiffs and "Files" (some systems call these "matters" or "actions").
>>
>>Here is what I wrote up for them - my problem is that I do not have a formal computer science training to know if there is a term to describe some of these things (other than ones like "referential integrity" when I use that below).
>>
>>Can anyone make any suggestions to terms that I should use below to make the below more understandable and/or professional? I have put some square brackets in places where it would be helpful to have a name for the principle. thanks for any help.
>>
>>>>>>>>>>>>>>>>>>>>> from my notes to them >>>>>>>>>>>>>>>>>>>>>
>>
>>Generally: good design states that a piece of information should only ever be kept in one place and if needed elsewhere, it should be linked not copied. This applies to both data (e.g. birthdate) or documents (that apply to more than an one file) e.g. a Proof of Age document. [this is called?][Don't Repeat Yourself (DRY) principle] . DRY is general, in the context of RDBMSs it's "database normalization".
>
>If you're dealing with lawyers or other non technical users you might want to add a little background, such as:
>
>"Modern business software is built using industry-standard relational databases. Best practices require the data they store to be normalized i.e. not duplicated unless absolutely necessary. Denormalized databases are less reliable and cost more to implement and maintain [for your reasons below]"
>
>>This is done so that if a piece of data or document is updated, it is updated once and the changes show everywhere, instantly; also done so that all copies do not have to be found and updated; likewise, if a piece of data is deleted, it is only deleted in one place (with “referential integrity” rules used to make sure that it cannot be deleted if something else is still using the data)
>>
>>Therefore: our decisions need to indicate if a document should be linked or indeed it needs to be copied because somehow, the document needs to be copied and then independently edited in the two files.
>
>I like those two paragraphs.
>
>Maybe they have higher-level concerns, that may be sticking points (?):
>
>- Do lawyers need copies of files they can take on a laptop to court i.e. offline?
>
>- Do they have a need to preserve different versions of files?
>
>- Are they concerned all their eggs are in one basket and they're vulnerable to data loss? If so then explanation of the backup system(s) may assuage those fears.
>
>>Second Principle: a piece of data or document should reside closest to the entity it relates to. e.g. a Proof of Age document should be linked to the Plaintiff since that is the entity it relates to; or a judgment that pertains to a settlement, should be linked to the file related to the judgment. [name for this?]
>>
>>If this information needs to be displayed elsewhere, the links between the entities (e.g. Plaintiff and Files) can be used to display the information as it is needed.
>
>Not sure what you'd call this. I'd guess you're discussing entities and attributes; in many cases which attributes to store against which entities is common sense and can be agreed upon and specified during database design. I gather it's possible to formally discuss "cardinality" and "modality" but that's going pretty deep, I've never had occasion to get into those.
>
>Taking a step back, it seems to me that all of the above are in a sense implementation details. If a client is specifying what they want a system to do, they shouldn't know or care about these things, any more than they should be worrying about primary and foreign keys.
>
>If your client wants to dive into these technical details, they need to be competent to discuss them. If they're not comfortable with DRY, database normalization and entities/attributes then you're fighting an uphill battle educating them as well as trying to get your specific ideas across.
>
>Maybe their existing database design is poor, and the people who originally designed it are now included in your discussions. Then it becomes an exercise in tact. The client may trust those people and not (yet) trust you to the same extent. At some point, if your technical viewpoint is to prevail, you need to establish your bona fides.
>
>Or maybe they've been seduced by some newfangled NoSQL database: https://www.youtube.com/watch?v=b2F-DItXtZs (comic relief)

b2F-DItXtZs