ارسال ایمیل در SQL-Server 
یک Resharper مخصوص SQL Server 
آیا این برنامه نیاز به نصب sql server دارد؟
یه موضوعی که تو این آمار بهش اشاره نشده تعداد و میزان حرفه ای بودن پروژه هایی هست که دارن از این دیتابیس ها استفاده میکنن. ممکنه این آمار اینجوری بدست اومده باشه که مثلا 10 تا سرور اوراکل تپل رو اومده مقایسه کرده باشه با 2تا سرور اس کیو ال معمولی و در این حالت باگ ها رو شمرده باشه. طبیعتا باگ های امنیتی اونی که در پروژه های بیشتری استفاده شده و سطح پروژه هم اینترپرایزتر هست ملموس تر هست. مثله قضیه ویندوز و لینوکس منظورم هست که اگه فراگیری ویندوز رو لینوکس هم داشت مطمئنا مورد حمله های بیشتری به نسبت ویندوز قرار می گرفت.
- عموما circular reference بین اسمبلی‌ها نشانه‌ی طراحی بد است.
- استفاده از چند Context برای اینکه هر کدام قرار است در یک دیتابیس جدا ذخیره شوند؟ نمی‌شود FK بین این‌ها (جداول دو دیتابیس مختلف) تعریف کرد (SQL Server چنین کاری را پشتیبانی نمی‌کند).
- اگر برنامه ماژولار است، در EF می‌توان به صورت خودکار تمام ماژول‌ها را در طی یک Context یکپارچه بارگذاری کرد (^ و ^).
- هدف از ایجاد Schema در SQL Server، ایجاد ظروفی برای گروه بندی منطقی اشیاء است. مثلا عده‌ای به سه SP خاص دسترسی داشته باشند. عده‌ای فقط بتوانند با Viewها کار کنند. یا حتی عده‌ای به تمام موارد دسترسی داشته باشند. بنابراین یک نوع ایزوله سازی قسمت‌های مختلف بانک اطلاعاتی مدنظر هست، در اصل. حالا اگر عده‌ای فقط به سه جدول خاص دسترسی دارند، آیا می‌توانند ارجاعی را به جدول چهارمی که در یک schema دیگر تعریف شده داشته باشند؟ بله. البته فقط به این شرط که کاربران schema سه جدول فعلی به schema جدول چهارم، دسترسی و مجوز لازم را داشته باشد و برای این دسترسی دادن‌ها هم باید مستقلا T-SQL بنویسید.
و ... ضمنا گاهی از اوقات از Schema برای مدیریت نام‌های هم نام استفاده می‌شود. چیزی شبیه به namespace در سی‌شارپ مثلا. نمونه‌اش طراحی چند مستاجری است.
نتیجه گیری؟ برای سرگرمی Schema ایجاد نکنید؛ مگر اینکه واقعا قصد ایزوله سازی قسمت‌های مختلف یک بانک اطلاعاتی را از کاربرانی خاص داشته باشید. به Schema به شکل یک Sandbox امنیتی (یک قرنطینه) نگاه کنید.
برای مطالعه بیشتر
Understanding the Difference between Owners and Schemas in SQL Server
Implementation of Database Object Schemas
- استفاده از چند Context برای اینکه هر کدام قرار است در یک دیتابیس جدا ذخیره شوند؟ نمی‌شود FK بین این‌ها (جداول دو دیتابیس مختلف) تعریف کرد (SQL Server چنین کاری را پشتیبانی نمی‌کند).
- اگر برنامه ماژولار است، در EF می‌توان به صورت خودکار تمام ماژول‌ها را در طی یک Context یکپارچه بارگذاری کرد (^ و ^).
- هدف از ایجاد Schema در SQL Server، ایجاد ظروفی برای گروه بندی منطقی اشیاء است. مثلا عده‌ای به سه SP خاص دسترسی داشته باشند. عده‌ای فقط بتوانند با Viewها کار کنند. یا حتی عده‌ای به تمام موارد دسترسی داشته باشند. بنابراین یک نوع ایزوله سازی قسمت‌های مختلف بانک اطلاعاتی مدنظر هست، در اصل. حالا اگر عده‌ای فقط به سه جدول خاص دسترسی دارند، آیا می‌توانند ارجاعی را به جدول چهارمی که در یک schema دیگر تعریف شده داشته باشند؟ بله. البته فقط به این شرط که کاربران schema سه جدول فعلی به schema جدول چهارم، دسترسی و مجوز لازم را داشته باشد و برای این دسترسی دادن‌ها هم باید مستقلا T-SQL بنویسید.
و ... ضمنا گاهی از اوقات از Schema برای مدیریت نام‌های هم نام استفاده می‌شود. چیزی شبیه به namespace در سی‌شارپ مثلا. نمونه‌اش طراحی چند مستاجری است.
نتیجه گیری؟ برای سرگرمی Schema ایجاد نکنید؛ مگر اینکه واقعا قصد ایزوله سازی قسمت‌های مختلف یک بانک اطلاعاتی را از کاربرانی خاص داشته باشید. به Schema به شکل یک Sandbox امنیتی (یک قرنطینه) نگاه کنید.
برای مطالعه بیشتر
Understanding the Difference between Owners and Schemas in SQL Server
Implementation of Database Object Schemas
SubSonic یکی دیگر از ORM های تهیه شده برای دات نت فریم ورک است که توسط یکی از اعضای مایکروسافت هدایت می‌شود. این پروژه سورس باز و رایگان است.
گردآوری جالبی است؛ قابل توجه دوستانی که با php و سرورهای لینوکسی کار می‌کنند.
همانطور که مطلع هستید نگارش نهایی SP1 مربوط به SQL Server 2008 مدتی است که ارائه شده است و یکی از قابلیت‌های آن Slipstreaming نصب آن است (من ترجمه‌اش می‌کنم "نصب ممزوج"). منظور از آن هم این است که تمام پچ‌های قبلی را می‌شود با نصاب ابتدایی یکی کرد. (بنابراین نصب ممزوج معادل بدی نیست، "دایر کردن فرو رفتنی" هم به فرهنگستان پیشنهاد می‌شود :) )
برای مثال در SQL server 2005 شما مجبور هستید که ابتدا نگارش RTM آن‌را نصب کنید و بعد آخرین سرویس پک ارائه شده را، اما در حالت پشتیبانی از نصب ممزوج، می‌شود فایل‌های سرویس پک را مستقیما بر روی فایل‌های نصاب اولیه بازنویسی کرد و به این صورت با نصب آن، به یکباره SQL Server 2008 SP1 را خواهید داشت و دیگر نیازی به reboot های مکرر و توقف و راه اندازی سرویس‌های گوناگون ویندوز نیست (این مساله در یک سرور حائز اهمیت است).
