スキーマレスなデータ構造がよく理解されていない。NoSQLデータベースでこれらのデータ構造を使用する際に、その長所と短所を考慮することは、重要だ。最近の会社のイベントでMartin Fowler氏は,スキーマレスデータ構造とNoSQL＆一貫性について話をした。
スキーマレスデータ構造:
スキーマレスであることは、しばしばNoSQLデータベースの大きな利点として考えられている。マーティンはこの領域が十分に理解されていないと信じており、スキーマレスなデータ構造を使用することの何が長所と短所あるかばかりでなく、スキーマレスの様々な面を説明している。
重要な点は、スキーマレス構造であっても尚スキーマを持っているということだ。データをクエリして情報を検索するためには、データを理解する必要があり、それは暗黙のスキーマ、データの定義が例えばコードの中にある。対照的に、正しいデータのみが受理されるリレーショナル・データベース内のスキーマは、明示的なスキーマ である。
氏は、この話の終わりに、ほとんどは、"Implicit Schema == Bad Thing" で、明示的なスキーマを使って、データがどんなものか、明確に定義する方が良い。確かにスキーマレスが役に立つ場合が少々あるが。しかし彼は、またスキーマは、固定したストレージスキーマである必要はなく、データアクセス層やXMLスキーマのようなもっと契約の形をとってもよい、と言った。
NoSQLと一貫性:
この講演で、氏はNoSQLデータベースにおける一貫性の2つの側面について論じた。
１つのデータベースで開発している時、論理的一貫性がデータの一貫性の維持を取り扱う。殆どのNoSQLデータベース（グラフは1つの例外である）に対して、集合 （ドメイン駆動デザインから来た概念で、オブジェクトのクラスタを同時に保存する）の使用は、矛盾を回避する明白なやり方である。
幾つかの場所に同じデータをコピーすることで、レプリケーションの一貫性を保つ、話している時に、氏はCAP 定理を持ちだした。ネットワーク上でデータが既に複製されていれば、それは一貫性と可用性の間の選択であると単純化した。彼が強調したのは、これは技術的な問題ではなく、一貫性と可用性のどちらを優先させるか、というビジネス上の選択だ、ということである。
氏は、ソフトウェアデザインの価値と技術的負債を議論する話で講演を締めくくった。