نظرات مطالب
استفاده از خواص راهبری در Entity framework بجای Join نویسی
با سلام
به موضوع جالب و کاربردی ای اشاره فرمودید.

لطفا روش کار در هنگامی که ارتباط دو جدول به صورت یک به چند باشد و قصد بازیابی رکورهایی را از جدول اول در حالتی که حداقل یک رکورد در جدول دوم با شرط ما وجود داشته باشد را بیان فرمایید.

مثلا جدول کارمندان یک شرکت با شرکت هایی که هر فرد قبلا در آن سابقه کار داشته است.
میخواهیم کارمندانی را که در شرکت x  کار کرده اند را به دست آوریم.

با تشکر از مطالب مفید شما.
نظرات مطالب
اهمیت code review
عجب!!!
آخه مگه دو تا select متفاوت از یه جدول توی یک فرمان انجام میشه!
اونم توی دستوری مثل login جالبه .....
پاسخ به بازخورد‌های پروژه‌ها
تغییر سایز جدول اصلی
جدول آن تمام عرض صفحه را پر می‌کند. البته می‌توان DocumentMargins را هم تنظیم کرد؛ جزو متدهای تنظیمی DocumentPreferences است.  
بازخوردهای پروژه‌ها
افزودن جدول به فوتر سفارشی
با سلام.
چگونه می‌شود یک جدول را به فوتر سفارشی اضافه کرد؟ متد مورد نظر را پیدا نکردم.
با تشکر.
بازخوردهای پروژه‌ها
اضافه کردن یک ردیف بالای جدول
با سلام،میشه یک ردیف برای نمایش عنوان به بالای جدول اضافه کنیم.من اضافه کردن row رو نتونستم پیدا کنم؟  

مطالب
الگوریتم های داده کاوی در SQL Server Data Tools (SSDT) - قسمت اول (مقدمه)
پیشتر مطالبی در رابطه با مفاهیم مخزن داده و داده کاوی در سایت آمده است: ^ و ^ و ^.

در این سری مقالات به معرفی الگوریتم‌های داده کاوی مایکروسافت و نحوه کار کردن با آن‌ها در محیط SQL Server Data Tools (SSDT)  می‌پردازیم. بیشتر متن مقاله ترجمه آزاد از کتاب معروف  Data Mining with Microsoft SQL Server 2008 می باشد که یکی از بهترین کتاب‌ها در زمینه داده کاوی است. از آنجائیکه دسته بندی الگوریتم‌های داده کاوی در SQL Server 2016 نسبت به SQL Server 2008 قدری متفاوت می‌باشد و کتاب فوق به دلیل ورژن SQL قدیمی‌تر، این موضوع را درنظر نگرفته است، بنابراین تغییرات ورژن جدید دسته بندی الگوریتم‌ها نیز لحاظ شده است. جهت درک بهتر مطالب، سعی شده‌است مثال و توضیحاتی براساس تجربه کاری  آورده شود.
برای دریافت SSDT می‌توانید به اینجا مراجعه نمایید.
پس از دریافت و نصب SSDT می‌توان به Visual Studio مراجعه نمود و یک پروژه Analysis Services Multidimensional and Data Mining یا به اختصار  SSAS-M را به شکل زیر ایجاد کرد.

 پس از ایجاد یک پروژه SSAS-M می‌توان در بخش Mining Structure یک ساختار داده کاوی را به شکل زیر ایجاد نمود.

حال بایستی توسط ویزارد، ساختار داده کاوی مورد نظر را ایجاد نمود. در صفحه اول ویزارد، مخزن داده را مشخص می‌نماییم.

در صفحه بعد الگوریتم موردنظر را انتخاب می‌نماییم.

بدیهی است که پس از ساخت ساختار داده کاوی می‌توان الگوریتم‌های دیگری را نیز برای مدل کردن مخزن داده به کار برد.

در این مقاله فرض شده است که خواننده نحوه ساخت  Cube  و  Dimension  را در یک پروژه SSAS-M توسط SSDT ، می‌داند. در صورتیکه به داده کاوی و هوش تجاری علاقمند هستید و به مقدمات بیشتری در رابطه با مطالب فوق نیاز دارید، پیشنهاد می‌شود که فصل‌های یک، سه و چهار کتاب فوق را جهت آشنایی بیشتر مطالعه نمایید.

همانطور که در شکل آخر نیز نشان داده شده است SSDT دارای الگوریتم‌های زیر است:

  • Microsoft_Naive_Bayes
  • Microsoft_Decision_Trees
  • Microsoft_Linear_Regression
  • Microsoft_Clustering
  • Microsoft_ Association_Rules
  • Microsoft_Neural_Network
  • Microsoft_Logistic_Regression
هدف این سری مقالات که به امید خدا در آینده منتشر خواهد شد، آشنایی با الگوریتم‌های داده کاوی فوق و نحوه مدل کردن مخزن داده توسط این الگوریتم‌ها و در نهایت چگونگی تفسیر مدل های داده کاوی تولید شده، می‌باشد.
مطالب
بازسازی کد: جابجایی متد (Move method)
معمولا زمانیکه متدی از امکانات کلاس دیگری غیر از کلاسی که در آن تعریف شده است استفاده می‌کند، نیاز به چنین بازسازی کدی داریم. روش کلی این بازسازی کد، انتقال متد به کلاسی است که بیشترین تعلق را به آن دارد! 
جابجایی متد یکی از موارد پر تکرار و مهم در امر بازسازی کد است. این بازسازی در مراحل انجام دیگر بازسازی‌های کد، مانند شکستن کلاس نیز استفاده می‌شود. با این روش ساده می‌توان کلاس‌هایی با مسئولیت‌های محدود و مشخص را توسعه داد.  

مراحل انجام این بازسازی کد  

  1. تمامی امکانات کلاس مبدا را که متد مورد نظر از آنها استفاده می‌کند، بررسی نمایید که آیا آنها نیز نیاز به انتقال دارند یا خیر. 
  2. کلاس‌های پدر و فرزند کلاس مبدا را برای یافتن تعاریف دیگری از متد مورد نظر بررسی نمایید. اگر تعاریف دیگری وجود داشتند به راحتی نمی‌توان متد را جابجا کرد. در این صورت اگر قصد جابجایی داشتید، باید به فکر جابجایی رابطه چند ریختی موجود نیز باشید. 
  3. متد را در کلاس مقصد ایجاد نمایید. 
  4. بدنه متد را به متد مقصد منتقل نمایید و تمامی امکانات استفاده شده در آن را طوری تغییر دهید که در کلاس جدید کار کند. اگر متد، نیاز به اشاره‌ای به کلاس مبدا داشت، باید تعیین نمایید که به چه صورت این اشاره انجام شود. اگر مکانیزم مدیریت خطایی (exception handling) در متد مبدا پیاده سازی شده بود، تعیین کنید که آیا متد مبدا نیز کماکان امر مدیریت خطا را انجام خواهد داد، یا به متد مقصد انتقال خواهد یافت. 
  5. کد کلاس مقصد را کامپایل و تست نمایید. 
  6. اگر متد مبدا را به عنوان فراخوان متد مقصد نگه داشتید، باید تصمیم بگیرید که کلاس مقصد در آن متد به چه صورت استفاده خواهد شد. 
  7. فراخوانی متد مقصد را به بدنه متد مبدا اضافه کنید. 
  8. کد را کامپایل و تست نمایید.
  9. در مورد سرنوشت متد مبدا تصمیم گیری نمایید که آیا نیازی به وجود آن هست یا خیر. در صورتیکه از متد مبدا در مکان‌های زیادی استفاده شده یا متد در کتابخانه یا فریم ورکی است که کنترلی بر روی استفاده کنندگان آن وجود ندارد، احتمالا باقی ماندن متد به عنوان صرفا فراخوان، ایده خوبی باشد. 
  10. اگر متد مبدا را حذف کردید تمامی استفاده از آن را باید به متد مقصد تغییر دهید. توجه داشته باشید ممکن است سناریو ساختن کلاس جدید با کلاس قدیمی متفاوت باشد. 
  11. مجددا کد را کامپایل و تست نمایید.  

مثال: فرض کنید نرم افزاری برای مدیریت رویدادها و شرکت کنندگان آن‌ها تهیه کرده‌ایم. در این نرم افزار، کلاسی با نام Event وجود دارد و کلاسی نیز با نام Person که نام آنها کاملا نمایانگر استفاده آنها است.
بخشی از بدنه این کلاس‌ها به صورت زیر است:  
public class Event 
{ 
    public List<Person> Participants { get; internal set; } 
} 
public class Person 
{ 
    public int Id { get; private set; } 
    public void Participate(Event ev) 
    { 
        var isParticipatedAlready = ev.Participants.Any(ff => ff.Id == Id); 
        if (isParticipatedAlready) 
            return; 
        ev.Participants.Add(this); 
    } 
}
در کد مربوط به کلاس Person، شاهد متدی هستیم که عمل ثبت‌نام فرد را در یک رویداد انجام می‌دهد. اما با دقت به این متد مشاهده می‌کنیم که بدنه این متد بیشتر از اعضای کلاس Event استفاده می‌کند. حتی این استفاده باعث شده است که خصوصیت Participants از کلاس Event به صورت public تعریف شود که خود مشکل دیگری در این طراحی است.
در چنین شرایطی، بازسازی کد جابجایی متد می‌تواند در راستای انتقال مسئولیت‌های مناسب هر کلاس به بدنه آن و بهبود طراحی کمک کند. بعد از بازسازی کد شاهد چنین طراحی‌ای هستیم:  
public class Event 
{ 
    protected List<Person> Participants { get; set; } 
    public void Participate(Person person) 
    { 
        var isParticipatedAlready = Participants.Any(ff => ff.Id == person.Id); 
        if (isParticipatedAlready) 
            return; 
        Participants.Add(person); 
    } 
} 
public class Person 
{ 
    public int Id { get; private set; } 
}
بازسازی‌ای که انجام شد، دو تاثیر را بر روی طراحی این کلاس‌ها داشته است:
   اول: جایگذاری بهتر و منطقی‌تر مسئولیت‌های یک کلاس 
   دوم: کپسوله سازی آسان‌تر کلاس ها 

بازسازی کد جابجایی متد، سنگ بنای بیشتر بازسازی‌های مورد نیاز در فعالیت‌های روزمره تولید یا نگهداری نرم افزار است. علارغم این که این بازسازی ساده به نظر می‌رسد، در مجموعه کدهای پیچیده، انجام این بازسازی ممکن است امری طاقت فرسا شود.  
نظرات مطالب
معماری لایه بندی نرم افزار #3
شاهین جان، من با حذف لایه مخزن مخالف هستم. زیرا:

ما لایه ای به نام "لایه مخزن" را میسازیم تا در نهایت کلیه متدهایی که برای حرف زدن با داده هامون را نیاز داریم داشته باشیم. حالا این اطلاعات ممکنه از پایگاه داده یا جاهای دیگه جمع آوری بشوند (و الزاما توسط EF قابل دسترسی و ارائه نباشند)

همچنین گاهی نیاز هست که بر مبنای چند متد که EF به ما میرسونه (مثلا چند SP) یک متد کلی‌تر را تعریف کنیم (چند فراخوانی را در یک متد مثلا متد X در لایه مخزن انجام دهیم) و در لایه بالاتر آن متد را صدا بزنیم (بجای نوشتن و تکرار پاپی همه کدهای نوشت شده در متد X)

علاوه بر این در لایه مخزن میشه چند ORM را هم کنار هم دید (نه فقط EF) که همونطور که آقای خوشبخت در کامنت‌ها نوشتند گاهی نیاز میشه.

بنابراین:
من وجود لایه مخزن را ضروری میدونم.

(فراموش نکنیم که هدف از این آموزش تعریف یک الگوی معماری مناسب برای پروژه‌های بزرگ هست و الا بدون خیلی از اینها هم میشه برنامه ساخت. همونطور که اکثرا بدون این ساختارها و خیلی ساده‌تر میسازند)

نظرات نظرسنجی‌ها
بعنوان مدیر تیم نرم افزاری با تعداد متوسط (6-7 نفر) با متدولوژی اسکرام، کدام روش را بیشتر می پسندید و استفاده می کنید؟
در تمامی تعاریف رسمی که از متدولوژی‌ها اومده، اونها رو در واقع به عنوان یک فریم ورک ( چهارچوب ) یا پروسس (فرآیند) کاری معرفی کرده. چرا؟ چونکه تیم نرم افزاری رو مجبور میکنه که از قوانین مربوط به خودش تبعیت کنه و برای اونها یک چهارچوب کاری تعریف میکنه تا تیم بر اساس اون فریم ورک یا چهارچوب حرکت کنن. مثلا خود RUP مخفف کلمات Rational Unified Process هست . RUP یک متدولوژی هست. اما در عنوان اصلی از اون به عنوان یک فرآیند یا فریم ورک عنوان شده. چرا میگن فرآیند؟ چون هر فرآیند به صورت مرحله مرحله اجرا میشه. و تیم از یک مرحله وارد مرحله جدید میشه. هم اسکرام و هم RUP به عنوان روشهای Agile شناخته میشن و هر دوتاشون بر مبنای تکرار Iteration هستن.
منابع برای مطالعه بیشتر :
نظرات مطالب
Identity و مباحث مربوطه (قسمت دوم) نحوه بدست آوردن مقادیر Identity
با تشکر از آقای نصیری و پاسخ مناسبی که ارائه کرده اند
در مورد استفاده از GUID به جای identity باید به یک نکته هم اشاره کنم که در بیشتر مواقع اگر مقدار GUIDی که به ازای یک فیلد UNIQUEIDENTIFIER تنظبم می‌کنید به صورت SEQUNTIAL نباشد باعث Fragment شدن ایندکس خواهد شد.
برای مقایسه بهتر بین  Fragmentation ایندکس مربوط به Identity و GUID به مثال زیر دقت کنید. هر دو مثال فیلد ID خود را به شکل Clustered Index دارند بعد از درج تعدادی رکورد مساوی در دو جدول Fragmentation مربوط به جدولی که دارای GUID است به شدت بالا است که این موضوع باعث کاهش کارایی خواهد شد

USE TEMPDB
GO
IF OBJECT_ID('TABLE_GUID')>0
DROP TABLE TABLE_GUID
GO
CREATE TABLE TABLE_GUID
(
ID UNIQUEIDENTIFIER PRIMARY KEY,
FirstName NVARCHAR(1000),
LastName NVARCHAR(1000)
)
GO
IF OBJECT_ID('TABLE_IDENTITY')>0
DROP TABLE TABLE_IDENTITY
GO
CREATE TABLE TABLE_IDENTITY
(
ID INT IDENTITY PRIMARY KEY,
FirstName NVARCHAR(1000),
LastName NVARCHAR(1000)
)
GO
INSERT INTO TABLE_GUID(ID,FirstName,LastName) VALUES (NEWID(),REPLICATE('FARID*',100),REPLICATE('Taheri*',100))
GO 10000

INSERT INTO TABLE_IDENTITY(FirstName,LastName) VALUES (REPLICATE('FARID*',100),REPLICATE('Taheri*',100))
GO 10000

--Fragmentation بررسی وضعیت 
SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(),OBJECT_ID('TABLE_GUID'),NULL,NULL,'DETAILED')
DBCC SHOWCONTIG(TABLE_GUID)
GO
SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(),OBJECT_ID('TABLE_IDENTITY'),NULL,NULL,'DETAILED')
DBCC SHOWCONTIG(TABLE_IDENTITY)
GO

خوب برای اینکه Fragmentation این نوع جداول را رفع کنید چند راه داریم
1- تولید GUID  به صورت Sequential (لازم می‌دانم اشاره کنم این قابلیت در SQL Server وجود دارد ولی مقدار تولید شده باید به شکل یک Default Constraint باشد که این موضوع نیازمند این است که شما اگر در سورس به این GUID نیاز پیدا کنید مجبور به زدن Select و... شوید. اگر بخواهید در سورس این کار را انجام دهید باید از Extentionهایی که برای اینکار وجود دارند استفاده کنید فکر کنم Nhibernate این حالت رو پشتیبانی کنه در مورد EF دقیقا اطلاع ندارم باید اهل فن نظر بدن)
2- تنظیم مقدار Fillfactor به ازای ایندکس
3-Rebuild و یا Reorganize دوره ای ایندکس