Coding Standards

1.  Schemaless:

Nosql

Variable state has different instances that have different values that need to be stored inside them.  Common state when most of the instances have the same value so it is easier to reteive.

the above is a method in which we can make our RDBMS system more flexible like NoSQL but make them more rigid then the NOSQL.

Then in our traditional schema we need the data that fits the schema. But in the predicate one we can handle different types of data and decide how we are going to handle that data.

We can use xml for this pupose. To keep a check on xml data we can use xml schema.. but now a days there is relax compact notation.

RELAX NG is a simple schema language for XML, based on [RELAX] and [TREX]. A RELAX NG schema specifies a pattern for the structure and content of an XML document. A RELAX NG schema thus identifies a class of XML documents consisting of those documents that match the pattern.

Consider a simple XML representation of an email address book:

<addressBook>  <card>    <name>John Smith</name>    <email>js@example.com</email>  </card>  <card>    <name>Fred Bloggs</name>    <email>fb@example.net</email>  </card></addressBook>

The DTD (as an internal subset) would be as follows:

<!DOCTYPE addressBook [<!ELEMENT addressBook (card*)><!ELEMENT card (name, email)><!ELEMENT name (#PCDATA)><!ELEMENT email (#PCDATA)>]>

A RELAX NG pattern for this could be written as follows:

element addressBook {  element card {    element name { text },    element email { text }  }*}

If the addressBook is required to be non-empty, then we can use + instead of *:

element addressBook {  element card {    element name { text },    element email { text }  }+}

Now let's change it to allow each card to have an optional note element:

element addressBook {  element card {    element name { text },    element email { text },    element note { text }?  }*}

Please refer to http://www.relaxng.org/compact-tutorial-20030326.html for more details.

You can have multiple schemas in it. You can extend one schema into the other.

2. Contextual Validation

http://martinfowler.com/bliki/ContextualValidation.html

Some recent readings made me think about saying a few preliminary things on the topic. One common thing I see people do is to develop validation routines for objects. These routines come in various ways, they may be in the object or external, they may return a boolean or throw an exception to indicate failure. But one thing that I think constantly trips people up is when they think object validity on a context independent way such as an isValid method implies.

I think it's much more useful to think of validation as something that's bound to a context - typically an action that you want to do. Is this order valid to be filled, is this customer valid to check in to the hotel. So rather than have methods like isValid have methods like isValidForCheckIn.

One of the consequences of this is that saving an object to a database is itself an action. Thinking about it that way raises some important questions. Often when people talk about a context-free validity, they mean it in terms of saving to a database. But the various validity checks that make this up should be interrogated with the question "should failing this test prevent saving?"

In About Face Alan Cooper advocated that we shouldn't let our ideas of valid states prevent a user from entering (and saving) incomplete information. I was reminded by this a few days ago when reading a draft of a book that Jimmy Nilsson is working on. He stated a principle that you should always be able to save an object, even if it has errors in it. While I'm not convinced that this should be an absolute rule, I do think people tend to prevent saving more than they ought. Thinking about the context for validation may help prevent that.

Implicit schema == bad

Prefer explicit schema.....

can refer to everything in details in http://martinfowler.com/articles/schemaless/

• Being schemaless reduces ceremony(you don't have to define schemas) and increases flexibility (you can store all sorts of data without prior definition)
• A Dictionary (aka Hash | Associative Array | Map) is a common way to make a schemaless data structure in memory. The notion of an implied schema still applies, there is little difference between aCustomer.firstname andaCustomer['firstname']
• http://martinfowler.com/articles/consumerDrivenContracts.html
• https://en.wikipedia.org/wiki/Design_by_contract
• http://martinfowler.com/articles/evodb.html