Timeline یک جدول نیست؛ یک گزارش هست از اطلاعات موجود (گزارش از اینکه یک کاربر به چه بلاگهایی علاقمند است). به ازای هر View جدید مورد نیاز از بانک اطلاعاتی، یک جدول جدید ایجاد نمیکنند. همچنین در اینجا چیزی به نام جدول نداریم. این بانک اطلاعاتی، سندگرا است. هر رکورد آن یک سند JSON است و مجموعهای از آنها تا حدودی شبیه به یک جدول بانک اطلاعاتی رابطهای است (تا حدودی از این جهت که هر سند JSON آن میتواند ساختار متفاوتی با قبلی داشته باشد، یا نداشته باشد؛ بسته به انتخاب و طراحی). در مورد «denormalized references» در متن بحث شده: «... بنابراین بهترین حالت استفاده از روش denormalized references محدود خواهد شد به موارد ذیل ... ». یعنی همه جا قرار نیست کار رفع نرمال سازی در بانکهای اطلاعاتی NoSQL سندگرا انجام شود. سه مورد مهم دارد که در بحث ذکر شدهاست.
در اینجا برای طراحی حالت بلاگهای مورد علاقه یک شخص در RavenDB فقط کافی است از مفهوم Includes آن استفاده کنید (نمونه آن «Includeهای یک به چند» در بحث). داخل کلاس User، یک آرایه شبیه به SupplierIds (مثال زده شده) به نام FavoriteBlogIds خواهید داشت. بارگذاری و گزارشگیری از آن برای نمایش لیست این بلاگها و سپس مطالب آنها، مانند مثالهای Include و Load ایی است که ارائه شد.
بنابراین در اینجا به چیزی مانند دو جدول مجزای کاربران و جدول ذخیره سازی لیست بلاگهای محبوب آنها نیازی نیست. لیست و آرایه Idهای بلاگهای مورد علاقهی یک کاربر، داخل سند JSON همان کاربر قرار میگیرد.
در اینجا برای طراحی حالت بلاگهای مورد علاقه یک شخص در RavenDB فقط کافی است از مفهوم Includes آن استفاده کنید (نمونه آن «Includeهای یک به چند» در بحث). داخل کلاس User، یک آرایه شبیه به SupplierIds (مثال زده شده) به نام FavoriteBlogIds خواهید داشت. بارگذاری و گزارشگیری از آن برای نمایش لیست این بلاگها و سپس مطالب آنها، مانند مثالهای Include و Load ایی است که ارائه شد.
بنابراین در اینجا به چیزی مانند دو جدول مجزای کاربران و جدول ذخیره سازی لیست بلاگهای محبوب آنها نیازی نیست. لیست و آرایه Idهای بلاگهای مورد علاقهی یک کاربر، داخل سند JSON همان کاربر قرار میگیرد.