行のサイズ、またはフィールドに格納するデータの量に制限はありません。ただし、各表および行のサイズを決める際、ストアのパフォーマンスを考慮する必要があります。どのデータ格納方法でもそうですが、行が大きくなるほど、格納場所からの情報の読取りと格納場所への情報の書込みに時間がかかります。

その一方で、各表の行には一定のオーバーヘッドが伴います。また、行の数が非常に多くなると、検索時間に悪影響を及ぼします。その結果、多数の表を使用する場合、各表はフィールド数が少ない行を使用するため、ストアのパフォーマンスが低下する可能性があります。

したがって、表の内容を設計する際、多数の行を使用する少数の表と、少数の行を使用する多数の表との間で適切なバランスを見つける必要があります。特定の情報がアクセスされる頻度を考慮する必要もあります。

たとえば、表にユーザーに関する情報が含まれ、各ユーザーは名と姓で識別されるとします。各ユーザーについて保持する情報のセットがあります。この情報には、サイズの小さなものもあれば、大きなものもあります。頻繁にアクセスされる情報もあれば、あまりアクセスされない情報もあります。

小さなプロパティには次のようなものがあります。

大きなプロパティには次のようなものがあります。

このデータを編成する方法はいくつか考えられます。方法は、データ・アクセス・パターンによって異なります。

たとえば、行にアクセスするたびに、前述のすべてのプロパティを読み書きする必要があるとします。(これはあまりないことですが、単純なケースの例です。)その場合、アプリケーションで、ユーザーについて保持する各プロパティのフィールドを含む複数の行を作成します。

ただし、ユーザーの情報にアクセスするたびに、アプリケーションでそのユーザーのすべてのプロパティにアクセスする必要がなくなる可能性が高くなります。ユーザー検索を行うたびにすべてのプロパティを必ず読み取る必要がある場合はありますが、更新時は多くの場合、一部のプロパティのみが操作されます。

このようなことから、データがアクセスされる頻度とデータのサイズを考慮することが有用です。あまりアクセスされない大きなプロパティは、頻繁にアクセスされるプロパティとは別の表に配置する必要があります。

たとえば、前述のプロパティに対して、アプリケーションで次のようなことが必要だとします。

この場合、表と子表を使用してユーザー・プロパティを格納できます。親表は、すべての小さいプロパティと公開鍵を含む行を保持します。子表にはイメージ・ファイルと音声あいさつが含まれます。

CREATE TABLE userInfo (
    surname STRING,
    familiarName STRING,
    gender ENUM (male,female),
    street STRING,
    city STRING,
    state STRING,
    zipcode STRING,
    userPhone STRING,
    publickey1 BINARY,
    publickey2 BINARY,
    PRIMARY KEY (SHARD(surname), familiarName)
)

CREATE TABLE userInfo.largeProps (
    propType STRING,
    voiceGreeting BINARY,
    imageFile BINARY,
    PRIMARY KEY (propType)
)

親表には、ユーザー・データにアクセスしたときにアクセスされるすべてのデータが含まれるため、1回の原子的操作でデータを一度に更新できます。同時に、イメージ・データと音声あいさつを子表に分割することで、行を取得するときに大きいデータ値を取得しないようにできます。