‫۹ سال و ۸ ماه قبل، شنبه ۴ بهمن ۱۳۹۳، ساعت ۰۰:۳۳
Timeline یک جدول نیست؛ یک گزارش هست از اطلاعات موجود (گزارش از اینکه یک کاربر به چه بلاگ‌هایی علاقمند است). به ازای هر View جدید مورد نیاز از بانک اطلاعاتی، یک جدول جدید ایجاد نمی‌کنند. همچنین در اینجا چیزی به نام جدول نداریم. این بانک اطلاعاتی، سندگرا است. هر رکورد آن یک سند JSON است و مجموعه‌ای از آن‌ها تا حدودی شبیه به یک جدول بانک اطلاعاتی رابطه‌ای است (تا حدودی از این جهت که هر سند JSON آن می‌تواند ساختار متفاوتی با قبلی داشته باشد، یا نداشته باشد؛ بسته به انتخاب و طراحی). در مورد «denormalized references» در متن بحث شده: «... بنابراین بهترین حالت استفاده از روش denormalized references محدود خواهد شد به موارد ذیل ... ». یعنی همه جا قرار نیست کار رفع نرمال سازی در بانک‌های اطلاعاتی NoSQL سندگرا انجام شود. سه مورد مهم دارد که در بحث ذکر شده‌است.
در اینجا برای طراحی حالت بلاگ‌های مورد علاقه یک شخص در RavenDB فقط کافی است از مفهوم Includes آن استفاده کنید (نمونه آن «Includeهای یک به چند» در بحث). داخل کلاس User، یک آرایه شبیه به SupplierIds (مثال زده شده) به نام FavoriteBlogIds خواهید داشت. بارگذاری و گزارشگیری از آن برای نمایش لیست این بلاگ‌ها و سپس مطالب آن‌ها، مانند مثال‌های Include و Load ایی است که ارائه شد.
بنابراین در اینجا به چیزی مانند دو جدول مجزای کاربران و جدول ذخیره سازی لیست بلاگ‌های محبوب آن‌ها نیازی نیست. لیست و آرایه Idهای بلاگ‌های مورد علاقه‌ی یک کاربر، داخل سند JSON همان کاربر قرار می‌گیرد.
‫۹ سال و ۸ ماه قبل، شنبه ۴ بهمن ۱۳۹۳، ساعت ۰۰:۱۱
با سلام.
یک سوال در خصوص طراحی روابط  یک بلاگ دارم:
فرض کنید میخواهیم بخش تایم لاین را به برنامه اضافه کنیم بدین شرح: هر کاربری بتواند مشترک بلاگ‌های مورد علاقه اش شود و هر بار که به صفحه اول برنامه مراجعه میکند جدیدترین پست‌های بلاگ هایی که مشترک آنها بوده ببیند.
شاید یک نوع طراحی اینگونه باشد که جدولی داشته باشیم به نام «اشتراک» که در آن فیلد «نام کاربری نویسنده و نام کاربری مشترک» مورد نظر درج شود. سپس یک جدول هم داشته باشیم مثلاً به نام Timeline با فیلدهای «نام کاربری نویسنده، نام کاربری گیرنده، متن کامل مطلب و تاریخ ارسال».
هر زمان مطلب جدیدی منتشر شد، به ازای هر مشترک در جدول اشتراک، یک رکورد در جدول Timeline درج شود، در این حالت کار خواندن مطالب جدیدی که باید به کاربر نشان دهیم ساده میشود اما اگر یک کاربر مثلاً 10000 تا مشترک داشته باشد پس به ازای هر مطلب جدیدی که مینویسد باید 10000 رکورد در جدول Timeline درج شود، و اگر 100 نفر بخواهند مطلب بنویسند فکر کنم سیستم از کار بی افتد.
ممکن است من را راهنمایی کنید.  
ویرایش:
در این لینک صفحه 26   مطلب زیر رو هم پیدا کرم.

خوب زمانیکه یک متد قراره فراخوانی بشه، کلاس مربوط به اون هم باید وهله سازی بشه دیگه. نه؟! این جزو اصول ابتدایی کار هست. بعد این مشکلش چیه؟ یا چه اهمیتی داره وقتی اصل متد کش شده اصلا  اجرا نمیشه و یک ضرب نتیجه‌ش بازگشت داده میشه.
با سلام.
حتی اگر از AOP بجای کش سطح دوم استفاده شود، ایجاد یک نمونه جدید از کلاس مربوط به لایه سرویس اجتناب ناپذیر خواهد بود. برای بهبود آن شما چه راه حلی پیشنهاد میکنید؟
‫۹ سال و ۸ ماه قبل، چهارشنبه ۱ بهمن ۱۳۹۳، ساعت ۰۴:۱۳
البته خاصیت ریموت از نسخه 3.3.0 به بعد قابل استفاده نیست (+)، و قرار است به صور کلی در نسخه 4 این خاصیت حذف شود. (+)
برای نمایش اطلاعات به صورت فقط خواندنی می‌شود از این روش استفاده کرد:
<a id="@item.Id" class="detail" data-toggle="modal" data-target=".bs-example-modal-lg" href="#">جزئیات</a>

<div class="modal fade bs-example-modal-lg" tabindex="-1" role="dialog" aria-labelledby="myLargeModalLabel" aria-hidden="true">
    <div class="modal-dialog">
        <div class="modal-content">
            // نتیجه اطلاعات
        </div><!-- /.modal-content -->
    </div><!-- /.modal-dialog -->
</div><!-- /.modal -->

<script type="text/javascript">
        $(function() {
            $('.detail').click(function () {
                var selectedId = $(this).attr('id');
                // نتیجه اکشن متد زیر یک پارشال ویو است
                $.post('@Url.Action("GetRequestById")' + "/" + selectedId, function (data) {
                    $('.modal-content').html(data);
                });
            });
        });
</script>
‫۹ سال و ۸ ماه قبل، شنبه ۲۷ دی ۱۳۹۳، ساعت ۰۰:۵۹
«که همان بانک‌های اطلاعاتی رابطه ای است»
خیر. در اینجا در صورت لزوم کل اطلاعات مورد نیاز یک سند را می‌توان داخل آن قرار داد. دید طراحی اسناد NoSQL با جداول normalize شده بانک‌های اطلاعاتی رابطه‌ای یکی نیست. این مساله به همراه جزئیات بیشتری در قسمت‌های بعد مانند مدل سازی داده‌ها در RavenDB بحث شده‌است.
‫۹ سال و ۸ ماه قبل، جمعه ۲۶ دی ۱۳۹۳، ساعت ۲۳:۴۷
با سلام و احترام
در انتهای بحث فرمودید «نکته جالبی که در اینجا وجود دارد، عدم نیاز به join نویسی برای دریافت اطلاعات وابسته به یک شیء است». با توجه به این مطلب من دقیقا متوجه نشدم در مسئله زیر چه باید کرد:
هر answer و question توسط By مشخص میشود توسط چه کسی ارسال شده (مثلاً : "users/Vahid":"By")، و در سند users اطلاعات کامل هر کاربر مثل نام کاریری، ایمیل، آدرس و شماره تماس و... در زمان ثبت نام ذخیره شده است. سوال: اگر لازم باشد به ازای هر سوال یا جواب ایمیل و شماره تماس فرستنده را هم به کاربر نهایی نشان دهیم، باید در زمان ارسال سوال یا جواب ابتدا کاربر را با استفاده از By در users یافته و ایمیل و شماره تماس وی را خوانده و در سند آن سوال یا جواب ذخیره کنیم؛ یا باید هر زمان که سوال یا جوابی ارسال شد فقط نام کاربری را ثبت کنیم و در زمان نمایش سوال‌ها و جواب‌ها به کاربر مشحصات فرستنده را از users خوانده و همراه با خصوصیات دیگر به کاربر نشان دهیم، که این مورد آخر همان بانک‌های اطلاعاتی رابطه ای است.
‫۹ سال و ۸ ماه قبل، جمعه ۲۶ دی ۱۳۹۳، ساعت ۲۳:۲۹
« ابتدا این ساختار در بانک تشکیل میشود  »
خیر. این فقط ساختار یک سند است. سند بعدی را هر طور که علاقمند بودید طراحی و ثبت کنید. متد session.Store محدودیتی ندارد. همچنین جایی هم در برنامه این ساختار در ابتدای کار به بانک اطلاعاتی معرفی یا ثبت نمی‌شود. وجود یک کلاس در برنامه به معنی تشکیل ساختار آن در بانک اطلاعاتی نیست.
بدون اسکیما یعنی هر رکورد با رکورد قبلی یا بعدی خودش می‌تواند ساختار کاملا متفاوتی داشته باشد.
‫۹ سال و ۸ ماه قبل، جمعه ۲۶ دی ۱۳۹۳، ساعت ۲۳:۱۴
با سلام؛ در مفاهیم پایه آمده است بانک‌های اطلاعاتی no sql خصوصیت   Non-schematized/schema free یا بدون اسکیما  دارند، اما در این مطلب ابتدا شمای بانک مثل کلاس   Question یا Answer تعریف شده و در نتیجه ابتدا این ساختار در بانک تشکیل میشود و سپس داده‌ها در آن قرار میگیرد. ممنون میشوم بیشتر توضیح بدید.