نظرات مطالب
Contact me
آقا خیلی ممنون که وقت گذاشتین و جواب دادین .
پس از لحاظ مادی اصلا به صرفه نیست ... این قیمت پشت جلد رو ناشر انتخاب میکنه یا نویسنده کتاب ؟ یه سوال دیگه این هم که تالیف و ترجمه تفاوتی که با هم در هزینه ها ندارند ؟
نظرات مطالب
Contact me
سلام
چاپ کتاب خیلی ساده‌تر از آنی است که می‌شود تصور کرد.
کتاب رو تهیه می‌کنید به صورت یک فایل word و به همراه یک متن برای پشت جلد و تصویر روی جلد و غیره به ناشر می‌دهید (البته ناشر هر تصویری رو که دوست داشت روی جلد می‌زند!). همان روز با شما قرار داد می‌بندند و همین! (یکبار خودشان غلط یابی می‌کنند (منظور اضافه کردن غلط به کار شما است!) و نهایتا یکبار متن نهایی رو می‌خونید و امضاء می‌کنید)
ولی متاسفانه به عنوان یک کار نمی‌شود به آن نگاه کرد و مدتی است که دیگر آن‌را دنبال نمی‌کنم به دلایل زیر:
10 درصد پشت جلد را به شما خواهند داد. مثلا برای 6 ماه زحمت شما جهت تهیه یک کتاب می‌شود 400 تا 500 هزارتومان. حالا شما حاضرید 6 ماه سر کار بروید و این مقدار دریافت کنید؟! جالب اینجا است که به پخش کننده 40 درصد می‌دهند! (عمق فاجعه تا کجاست ...!)
ضمنا پرداخت آن هم اقساطی است و از 6 ماه بعد از انتشار کتاب شروع می‌شود. کتابی رو که الان تحویل بدید احتمالا 6 تا 9 ماه دیگر چاپ می‌شود.
بنابراین اصلا از لحاظ مالی مقرون به صرفه نیست مگر اینکه ابعاد معنوی کار برای شما مهم باشد.
نظرات مطالب
جزئیات برنامه نویسی افزونه فارسی به پارسی
واقعا دستت درد نکنه
چند تا سوال داشتم
میشه دیتا بیس رو xml گذاشت؟(با یونیکد مشکل پیدا نمیکنه!)
اگه امکان داره چند کتاب الکترونیکی خوب رو که در این زمینه ها مطالعه کردی معرفی کنید
مرسی
بازخوردهای پروژه‌ها
دریافت گزارشات فقط به صورت Excel
با توجه به اینکه امکان تولید خودکار گزارشات اکسل به کمک این کتاب خانه فراهم است ، آیا ممکن گزارشات را فقط به صورت اکسل دریافت کرد ؟ 
یعنی آدرس خروجی را بدهیم و فایل اکسل در آنجا ذخیره شود.
مطالب
معماری وب گرا (سبکی از سرویس گرایی)
در ابتدای مقاله، پیش از آن که وارد بحث معماری وب گرا بشوم، یک سوال را مطرح میکنم که شاید برای شما هم جالب باشد. آن سوال اینست : آیا SOA پاسخی برای همه چیز در 
حوزه معماری است؟ شاید اینطور نباشد. به ترکیب زیر دقت کنید :
WOA  / SOA + WWW + REST
ترکیب فوق ما را چند قدم جلوتر برده و کاستی‌های سرویس گرایی را پر می‌کند و ما را یاری می‌کند تا اپلیکیشن‌های کامل end-to-end بسازیم.

اگر چه مفهوم WOA شاید چندان فراگیر نباشد، ولی بسیاری از آنچه تاکنون در سطح اینترنت می‌بینیم شالوده همین تفکر وب گرایی است.

معماری وب گرا یا Web-Oriented Architecture در 2006 توسط  Nick Gall از گروه Gartner ابداع شده است. 
معماری وب گرا یک سبک معماری نرم افزاری است که معماری سرویس گرا (Service-Oriented Architecture) را در راستای اپلیکیشن‌های تحت وب گسترش می‌دهد. 
معماری وب گرا در اصل توسط بسیاری از شبکه‌های اجتماعی و وب سایت‌های شخصی ساخته شده است.

تعریف رسمی Gartner از معماری وب گرا چنین است :
 “معماری وب گرا یا Web-Oriented Architecture سبکی معمارگونه از معماری سرویس گرا یا همان Service-Oriented Architecture می‌باشد که به یکپارچگی سیستم‌ها و کاربران از طریق ابررسانه‌های مرتبط با هم در سطح جهانی بر اساس معماری وب می‌پردازد.
 این نوع معماری بر تمامی اینترفیس‌ها (رابط کاربری و  رابط کاربردی برنامه نویسی) به منظور دستیابی به تاثیرات شبکه‌ی جهانی از طریق پنج عنصر رابط اساسی ذیل تاکید دارد :
  • شناسایی منابع
  • بکارگیری منابع از طریق نمایش آنها (منابع وب)
  • پیام‌های خودتوصیفی
  • ابررسانه بعنوان قلب تپنده موقعیت برنامه
  • درگیر نکردن برنامه “
Nick Gall همچنین فرمولی را برای تعریف معماری وب گرا (WOA) ارائه داده است که بدین شکل است:
WOA = SOA + WWW + REST

Dion Hinchcliffe مدعی است که معماری وب گرا چنین است: 

“مجموعه‌ای از هسته پروتکل‌های وب مانند HTTP, XML است و اینکه تنها تفاوت معماری سرویس گرای سنتی و مفاهیم معماری وب گرا اینست که WOA از REST حمایت می‌کند. REST متدی به طور فزاینده محبوب ، قدرتمند و ساده به منظور اعمال نفوذ پروتکل انتقال ابر متن HTTP بعنوان یک وب سرویس در چارچوب حقوق خودش است.“

پشته‌ی معماری وب گرا WOA شامل چنین مواردی است :
  • توزیع (HTTP , Feeds)
  • ترکیب (Hypermedia , Mashups)
  • امنیت (Open ID, SSL)
  • قابلیت انتقال داده (XML,RDF)
  • قابلیت نمایش داده (ATOM, JSON)
  • متدهای انتقال (REST, HTTP, Bit Torrent)

بطور کل باید گفت WOA هر چیزی است که در اینترنت وجود دارد و هر چیزی که بر مبنای REST می‌باشد والبته سرویس گراست. در کلامی گویا باید گفت امروزه معماری وب گرا پراستفاده‌ترین نوع معماری در جهان تا به امروز بوده است. طبق پیش بینی Gartner در 2014 سبک معماری وب گرای (مبتنی بر REST) در 80% سازمان هایی که سرویس گرایی را دنبال می‌کنند فراگیر خواهد شد. واقعا صحت یا عدم صحت تحقق این پیش بینی Gartner شاید مهم نباشد ؛ چرا که هر کسی می‌بایست WOA را بشناسد.
اما REST چیست ؟ Representational State Transfer سبکی از معماری نرم افزار برای سیستم‌های ابررسانه توزیع شده مانند شبکه جهانی وب است (منبع : ویکی پدیا). با هم اصول REST را مرور کنیم:
  • هر چیزی یک منبع است.
  • هر منبعی یک تمثیل دارد.
  • هر منبعی یک نام بخصوص دارد.
  • انتقال موقعیت نیازمند کشف و شهود (Discovery) است.
  • پروتکل شبکه پایه WOA می‌باشد

بطور خلاصه WOA را بررسی می‌کنیم :
  • اطلاعات در قالب منابع (Resources) نمایش می‌یابند.
  • منابع توسط URI‌ها شناخته می‌شوند.
  • منابع از طریق HTTP اداره می‌شوند.
  • معاهدات به صورت ضمنی در نمایش منابع می‌باشند.
  • رابط‌ها بطور کلی عام هستند.

معماری وب گرای سازمانی
معماری وب گرای سازمانی یا Enterprise Web Oriented Architecture (EWOA) یکی از زیر سبک‌های SOA می‌باشد. EWOA مجموعه ای از عناصر، اصول و فرآیندهای معماری مبتنی بر وب می‌باشد. وب سایت‌ها و برنامه‌های کاربردی جدید مانند Google AdSense, Wikipedia و دیگر سرویس‌های RESTful از WOA استفاده می‌کنند.
مثال حال حاضر WOA را می‌توان Google’s Open Social  یا MindTouch دانست. در حال حاضر Mobile API بنایی اساسی بر تمرکز در استفاده از تکنولوژی WOA را دارند. ساخت چنین سرویس هایی با استفاده از پروتکل‌های ساده شده وب نظیر Rest , JSON بیش از پیش آسان شده است. این پروتکل‌ها برای توسعه دهندگان وب بسیار راحت‌تر است چرا که CPU و پهنای باند کمتری را طلب می‌کنند. این پروتکل‌ها بیشتر بخاطر شبکه‌های اجتماعی بزرگ نظیر فیس بوک ، آمازون ، توییتر و … شناخته شده‌اند.
MindTouch هم یک شرکت اوپن سورس و یک سکوی مستندسازی استراتژیک و نوعی جدید از ECM می‌باشد. از جمله پروژه‌هایی که ارایه کرده‌است می‌توان به موارد ذیل اشاره کرد :
DReAM
SGML Reader
MindTouch Core/2010
در ادامه، بکارگیری REST را در قالب شبکه جهانی وب (W3) در قالب جدول زیر با دیدگاه مقایسه‌ای با تلفیق در وب بررسی می‌کنیم:
{بنده می‌گویم} REST بدون WWW بی معناست. REST با Web است که تکمیل می‌شود و معنا پیدا می‌کند.

بررسی مزایای WOA
  • ساده سازی توسعه پذیری، مقیاس پذیری
  • کاهش زمان توسعه ویژگی‌های جدید
  • کاهش زمان مهندسی مورد نیاز برای یکپارچه سازی
  • سازنده فرصت‌هایی جدید برای mash-ups و دیگر داستان‌های غیرقابل پیش بینی کاربری
  • اما وضعیت ارتباطی کلاینت‌ها و سرورها در WOA چگونه است ؟
  • سرویس‌ها وابسته به دیگر سرویس‌ها هستند.
  • ارتباطات از طریق HTTP صورت می‌گیرد.
  • کلاینت‌ها حکم منبع و سرویس دهی به دیگر کلاینت‌ها را دارند.
  • مقیاس پذیری ، توسعه پذیری == اتصالات داخی 


بعنوان مثال می‌توان با ترکیب تصاویر و آدرس‌های مختلف دانشگاه‌های تهران، یک map Mashup درست کرد.


برای Photo Mashup ابزار Color Picker هم هست که امکان جستجوی تصاویر را بر اساس رنگ فراهم می‌کند و از سرویس اشتراک گذاری عکس Flickr استفاده می‌کند که در این آدرس قابل استفاده است.


معماری Mashup هم مثل معماری MVC (البته با تفاوت‌های فاحش) سه لایه‌ای است :


لایه نمایش / تعامل کاربر (همان رابط کاربری است)

تکنولوژی‌ها : HTML/XHTML, CSS, Javascript, Asynchronous JS and Xml (Ajax).

وب سرویس‌ها : عملکرد محصول از طریق سرویس‌های API هم قابل دسترسی است

تکنولوژی‌ها : XMLHTTPRequest, XML-RPC, JSON-RPC, SOAP, REST

داده : فراهم آوردن امکان ارسال ، مرتب سازی و دریافت داده

تکنولوژی‌ها : XML , JSON , KML

از نظر معماری  Mashup  دارای 2 سبک است : الف) مبتنی بر وب – ب) مبتنی بر سرور


 در ادامه با هم نمونه ای از استقرار معماری وب گرا WOA را در سازمان، بصورت شماتیک می‌بینیم. با هم مشاهده می‌کنیم با این پیاده سازی، موانع سر راه ما کاهش پیدا می‌کنند و سرعت یکپارچگی افزایش پیدا می‌کند. بدین صورت که می‌توان از قدرت شبکه جهانی وب در جهت انتقال محتوای مورد نیازمان به هر جا و در هر زمانی بهره جست.


شاید برای شما سوال پیش بیاید که ما در معماری وب گرا بحث می‌کردیم، اصلا چرا وارد مفهوم Mashup شدیم؟


به‌عبارت فنی‌تر چرا معماری وب گرا (WOA) برای Mashups اهمیت دارد ؟

 پاسخ یک کلمه است : REST . همانطور که بالاتر نیز اشاره کردم، Mashup از REST بهره می‌برد. به منظور افزایش اطلاعات در رابطه با REST باید گفت Roy Fielding آنرا بنیان نهاده‌است. میخواهید او را بهتر معرفی کنم؟ وی یکی از خالقان HTTP است و مگر می‌توان وب را بدون HTTP فرض کرد که مهمترین پروتکل انتقال ابر متن در جهان و پروتکل زیربنایی وب است؟! 

REST به خوبی با معماری اینترنت عجین شده است! بپرسید چرا؟ چون پروتکل اصلی اینترنت HTTP است و هر دوی این‌ها از یک ذهن نشات گرفته و او کسی نیست جز Roy Fielding. اما باید بگویم REST یک استاندارد نیست؛ با وجود سادگی بسیار زیاد، تنها یک سبک استفاده از HTTP است.


REST همچنین از متدهای اختصاصی HTTP نظیر GET, PUT , POST , DELETE در بالای یک URL استفاده می‌کند تا نشان دهد چه رویدادی رخ می‌دهد.


در پایان گفته‌ها در رابطه با REST باید بگویم ATOM همان REST است. منظورم از ATOM ویرایشگر معروف متنی نیست که برای نوشتن کدهای برنامه نویسی استفاده قرار می‌گیرد؛ آنرا غالبا به شکل Atom می‌نویسند چرا که مخفف چند کلمه نیست و یک کلمه خاص است  اما ATOM یک استاندارد وب به زبان XML است که برای خوراک وب بعنوان جایگزینی برای RSS استفاده می‌شود. ATOM را با AtomPub یا APP اشتباه نگیرید؛ چرا که APP پروتکل انتشاری است مبتنی بر پروتکل انتقال ابرمتن (HTTP) و برای به روزرسانی محتوی وب مورد استفاده قرار می‌گیرد.


در ادامه مباحث دررابطه با معماری وب گرا باید گفت WOA امروزه بعنوان مدل حاکم برنامه‌های تحت شبکه مطرح است. اما متاسفانه فروشندگان بزرگی در پشت آن حضور ندارند به همین دلیل آنچنان که باید عمومیت نیافته است. WOA همچنان می‌تواند بیشترین سود حاصل را از طریق شبکه فراهم کند. شاید بتوان گفت کوتاه‌ترین مسیر برای رسیدن به چنین نتیجه‌ای همین معماری وب گرا است. 

فرمول جالبی هم برای تعریف وب ارائه شده‌است که با هم می‌بینیم :


HTTP + URIs = Web


ظرافت فرمول بالا به اهمیت پروتکل زیربنایی وب یعنی HTTP اشاره دارد. URI هم مجموعه‌ای از رشته‌هاست که برای شناسایی یک منبع خاص تحت وب به کار می‌روند. در شکل زیر رابطه بین URI , URN , URL را بررسی می‌کنیم. URI تشکیل شده‌است از URL و URN .URL متد دسترسی به منبع را مشخص می‌کند، در حالیکه URN تنها مشخص کننده نام منبع می‌باشد و هیچگونه روشی را برای دسترسی به ما ارائه نمی‌دهد. بعنوان مثال یک شماره ISBN کتاب، یک نوع URN است. 





مطالب
آموزش (jQuery) جی کوئری 1#
با سلام خدمت دوستان عزیز
تصمیم گرفتم در طی چندین پست در حد توانم به آموزش jQuery بپردازم. (مطالب نوشته شده برداشت ازادی از کتاب jQuery in action است)

جی کوئری (jQuery) چیست؟
jQuery یک کتابخانه بسیار مفید برای جاوا اسکریپت است. بسیار ساده و کارآمد است و مشکل جاوا اسکریپت را برای تطابق با مرورگرهای اینترنتی مختلف برطرف نموده است؛ یادگیریjQuery بسیار آسان است. در جی کوئری کد جاوا اسکریپت از فایل HTML جدا شده و بنابراین کنترل کدھا و بھینه‌سازی آنھا بسیار ساده‌تر خواھد شد. توابعی برای کار با AJAX فراھم نموده و در این زمینه نیز کار را بسیار ساده کرده است. در جی کوئری می‌توان از خصوصیت فراخوانی زنجیره‌ای متدھا استفاده نمود و این باعث می‌شود چندین کد فقط در یک سطر قرار گیرد و در نتیجه کد بسیار مختصر گردد. در مقایسه با سایر ابزارهایی که تاکید عمده‌ای بروی تکنیک‌های هوشمند جاوا اسکریپت دارند، هدف جی کوئری تغییر تفکر سازندگان وب سایت‌ها، به ایجاد صفحه‌هایی با کارکرد بالا می‌باشد. به جای صرف زمان برای مقابله با پیچیدگی‌های جاوا اسکریپت پیشرفته، طراحان می‌توانند با استفاده از زمان و دانش خود در زمینه‌ی CSS، HTML، XHTML و جاوا اسکریپت‌های ساده، عناصر صفحه را مستقیما دستکاری کنند و از همین طریق تغییرهای گشترده و سریعی انجام دهند.

نکته: برای استفاده از جی کوئری باید HTML و CSS و جاوا اسکریپت آشنایی داشته باشید.

چگونه از جی کوئری استفاده کنیم؟
برای استفاده از جی کوئری باید ابتدا فایل آن را از سایت آن دانلود کرده و در پروژه خود استفاده نمایید. البته روش‌های دیگری برای استفاده از این فایل وجود دارد که در آینده بیشتر با آن آشنا خواهیم شد. برای استفاده از این فایل در پروژه باید به شکل زیر آن را به صفحه HTML خود معرفی کنیم.
<html>
   <head>
       <script type="text/javascript" src="jquery-1.9.1.min.js"></script>
   </head>
   <body>
   </body>
</html>
سپس بعد از معرفی خط فوق در قسمت head صفحه باید کد‌های خود را در یک تگ script بنویسیم.

کوتاه کردن کد: هر زمان شما خواسته باشید کارکرد یک صفحه وب را پویا‌تر کنید، در اکثر مواقع به ناچار این کار از طریق عناصری بروی صفحه انجام داده اید که با توجه به انتخاب شدن آنها، صفحه کارکردی خاص خواهد داشت. مثلا در جاوا اسکریپت اگر بخواهیم عنصری را که در یک radioGroup انتخاب شده است را برگردانیم باید کد‌های زیر را بنویسیم:
var checkedValue;
var elements = document.getElementByTagName ('input');
for (var n = 0; n < elements.length; n++) {
       if (elements[n].type == 'radio' && elements[n].name == 'myRadioGroup' && elements[n].checked) {
               checkedValue = elements[n].value;
       }
}
اما اگر بخواهیم همین کد را با جی کوئری بنویسیم:
var checkedValue = $ ('[name="myRadioGroup"]:checked').val();
ممکن است مثال بالا کمی گنگ باشد نگران نباشید در آینده با این دستورات بیشتر آشنا خواهیم شد.
قدرت اصلی جی کوئری برگفته از انتخاب‌کننده‌ها (Selector) هاست، انتخاب‌کننده ، یک عبارت است که دسترسی به عنصری خاص بر روی صفحه را موجب می‌شود؛ انتخاب‌کننده این امکان را فراهم می‌سازد تا به سادگی عنصر مورد نظر را مشخص و به آن دسترسی پیدا کنیم که در مثال فوق، عنصر مورد نظر ما گزینه انتخاب شده از myRadioGroup بود.
Unobtrusive JavaScript: اگر پیش از پیدایش CSS در کار ایجاد صفحه‌های اینترنتی بوده‌اید حتما مشکلات و مشقات آن دوران را به خاطر می‌آورید. در آن زمان برای فرمت‌دهی به اجزای مختلف صفحه ، به ناچار علائم فرمت‌دهی را به همراه دستورات خود اجزا، در صفحه‌های HTML استفاده می‌کردیم. اکنون بسیار بعید به نظر می‌رسد کسی ترجیح دهد فرمت‌دهی اجزا را به همراه دستورهای HTML آن انجام دهد. اگر چه هنوز دستوری مانند زیر بسیار عادی به نظر می‌آید:
<button type="button" onclick="document.getElementById('xyz').style.color='red';">
        Click Me
</button>
نکته ای که در مثال فوق حائز اهمیت است، این است که خصوصیات ظاهری دکمه ایجاد شده از قبیل فونت و عنوان دکمه، از طریق تگ <font> و یا پارامترهای قابل استفاده در خود دستور دکمه تعیین نشده است، بلکه CSS وظیفه تعیین آنها را دارد. اما اگرچه در این مثال فرمت‌دهی و دستور خود دکمه از یکدیگر جدا شده‌اند؛ شاهد ترکیب این دکمه با رفتار آن هستیم. در جی کوئری می‌توانیم رفتار را از اجزا به آسانی جدا کنیم.

مجموعه عناصر در جی کوئری:

زمانی که CSS به عنوان یک تکنولوژی به منظور جداسازی طراحی از ساختار به دنیای صفحه‌های اینترنتی معرفی شد، می‌بایست راهی برای اشاره به اجزای صفحات از طرف فایل CSS نیز معرفی می‌شد. این امر از طریق انتخاب‌کننده‌ها (Selector) صورت پذیرفت.

برای مثال انتخاب‌کننده زیر، به تمام عناصر <a> اشاره دارد که در یک عنصر <p> قرار گرفته‌اند:

p a
جی کوئری نیز از چنین انتخاب‌کننده‌هایی استفاده می‌کند، الته نه تنها از انتخاب‌کننده‌هایی که هم اکنون در CSS موجود می‌باشند، بلکه برخی از انتخاب‌کننده‌هایی که هنوز در تمام مرورگرها پشتیبانی نمی‌شوند.
برای انتخاب مجموعه‌ای از عناصر از یکی از دو Syntax زیر استفاده می‌کنیم.
$(Selector)
یا
jQuery(Selector)
ممکن است در ابتدا ()$ کمی نا معمول به نظر آید، اما اکثر کسانی که با جی کوئری کار می‌کنند از اختصار و کوتاهی این ساختار استفاده می‌کنند.
مثال زیر نمونه‌ای دیگر است که در آن مجموعه‌ای از تمام لینک‌هایی که درون تگ <p> قرار دارند را انتخاب می‌کند:
$("p a")
تابع ()$ که در حقیقت نام خلاصه‌ای برای ()jQuery می‌باشد، نوع خروجی مخصوصی دارد که شامل یک آرایه از اشیایی می‌شود که انتخاب‌کننده آن را برگزیده است. این نوع خروجی این مزیت را دارد که شمار زیادی متد از پیش تعریف شده را داراست که به سادگی قابل اعمال می‌باشند.
در اصطلاح برنامه نویسی به چنین توابعی که گروهی از عناصر را جمع می‌کنند، Wrapper می‌گویند زیرا تمام عناصر مطلوب را تحت یک شی بسته‌بندی می‌کند. در جی‌کوئری به آنها Wrapped Set یا jQuery Wrapper می‌گویند و به متدهایی که قابل اعمال بروی اینها به نام jQuery Wrapper Methodes شناخته می‌شوند.
در مثال زیر می‌خواهیم تمام عناصر <div> در صورتی که دارای کلاس notLongForThisWorldباشند را مخفی (با فید شدن) کنیم.

$("div.notLongForThisWorld").fadeOut();
یکی از مزیت‌های اکثر متدهای قابل اجرا بروی مجموعه عناصر انتخاب شده آن است که خروجی خود آنها مجموعه‌ای دیگر است. به این معنا که خروجی این متد، آماده اعمال یک متد دیگر است.
فرض کنید در مثال بالا بخواهیم پس از مخفی کردن هر <div> بخواهیم یک کلاس به نام removedبه آن بیافزاییم. به این منظور می‌توان کدی مانند زیر نوشت:
$("div.notLongForThisWorld").fadeOut().addClass("removed");
این زنجیره متدها می‌توانند به هرتعداد ادامه پیدا کند.

چند نمونه  انتخاب کننده:

نتیجه
  انتخاب کننده
 تمام <p>‌های زوج را انتخاب می‌کند

$('p:even')
 سطر اول هر جدول را انتخاب می‌کند

$("tr:nth-child(1)");
 <div>هایی که مستقیما در <body> تعریف شده باشند را انتخاب می‌کند.

$("body > div");
 لینک هایی که به یک فایل pdf اشاره دارند را انتخاب می‌کند.

$("a[href$=pdf]");
 تمام <div> هایی که مستقیما در <body> معرفی شده اند و دارای لینک می‌باشند را انتخاب می‌کند.

$("body > div:has(a)")
   

ادامه مطالب در پست‌های بعدی تشریح خواهد شد.


جهت مطالعه بیشتر می‌توانید از این منابع ^  و  ^  و  ^  و  ^  و  ^ استفاده کنید.
موفق و موید باشید
مطالب
طراحی جدول فایل‌های پیوستی پایگاه داده
سناریو‌ی زیر را در نظر بگیرید:
می‌خواهید پروژه‌ای را انجام دهید که شامل جداول زیر است:
مقالات، اخبار، گالری تصاویر، گالری ویدیو، اسلایدشو، تبلیغات و ... و تمامی این جداول حداقل شامل یک فایل پیوست (عکس، فیلم، ...) می‌باشند. به طور مثال جدول مقالات دارای یک عکس نیز می‌باشد. قصد داریم تمام فایل‌ها را بر روی هاست ذخیره کرده و فقط آدرس و نام فایل را در دیتابیس ذخیره نمایم.

روش اول : استفاده از یک فیلد در هر جدول برای نگه دارای اسم فایل

مثال:
    public class Article
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string Body { get; set; }
        public string RegisterDate { get; set; }
        public string FileName { get; set; }
    }
معایب:
این روش فقط در صورتی پاسخگو می‌باشد که هر رکورد فقط شامل یک فایل باشد. به طور مثال ممکن است برای یک مقاله، چندین عکس و فایل را ضمیمه‌ی آن کنیم. در این حالت این روش پاسخ گو نمی‌باشد؛ ولی می‌توانیم به صورت زیر نیز عمل کنیم:
ایجاد جدولی برای نگهداری فایل‌های هر رکورد از مقاله :


public class ArticleFiles
{
        public int Id { get; set; }
        public string FielName { get; set; }
        public string FileExtension { get; set; } 
        public Article Article { get; set; }
        public int FileSize { get; set; }
}
 
روش دوم : ایجاد جدولی پایه برای نگهدارای تمام فایل‌های آپلود شده

می‌توانیم جدولی را به نام Attachment ایجاد کرده و هر فایلی را که آپلود می‌کنیم، مشخصات آن را در این جدول ذخیره کنیم و هر جدول هم که نیازی به فایل داشت، رابطه‌ای با این جدول برقرار کند. در این حالت خواهیم داشت:


public class Attachment
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string FileName { get; set; }
        public string Extension { get; set; }
        public DateTime RegisterDate { get; set; }
        public int Size { get; set; }
        public ICollection<Article> ArticleFiles { get; set; }
        public ICollection<News> NewsFiles { get; set; }
        public int Viewed { get; set; }
    }
در این حالت باید بین تمام جداولی که نیاز به فایل دارند، رابطه ای با جدول Attachment داشته باشد. به طور مثال بین جدول مقالات و جدول Attachment یک رابطه‌ی یک به چند برای لیست فایل‌ها وجود خواهد داشت.


روش سوم : جدولی برای نگه داری اسم فایل‌ها، بدون رابطه

جدول Attachment در این روش، همانند روش دوم می‌باشد؛ با دو تفاوت:
1- با هیچ جدولی رابطه‌ای ندارد.
2- دو فیلد به عنوان نام جدول و Id رکورد به آن اضافه شده است.
تفاوت نسبت به روش دوم:
در روش دوم، ثبت یک رکورد، وابسته‌ی به ثبت رکورد در جدول Attachment بود و ابتدا می‌بایستی فایل در Attachment ذخیره می‌شد و بعد از بدست آوردن Id آن، رکورد مورد نظر (مقاله) را درج می‌کردیم. ولی در این روش ابتدا مقاله درج شده و بعد از آن فایل را با اسم جدول و ID رکورد مورد نظر ذخیره می‌کنیم:
public class Attachment
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string FileName { get; set; }
        public string Extension { get; set; }
        public DateTime RegisterDate { get; set; }
        public int Size { get; set; }
        public string TableName { get; set; }
        public int RowId { get; set; }
        public int Viewed { get; set; }        
    }

حالت پنجم :

ایجاد یک کلاس پایه و ارث بری سایر کلاس‌ها از کلاس پایه و ایجاد رابطه‌ای بین کلاس پایه و کلاس‌های مشتق شده.

نظراتی پیرامون حالت‌های مختلف:

1- داشتن یک جدول الحاقات برای هر جدول
  • اضافه کردن یک فیلد: بعضی‌ها این روش را ترجیح می‌دهند. به این دلیل که هر جدول، یک جدول attachment مختص به خود دارد؛ با توجه به فیلدهایی که لازم است. به طور مثال ممکن است بعد از گذشت مدتی، نیاز باشد تا دو فیلد برای فایل‌های هر مقاله اضافه شوند که در این حالت فقط به جدول attachment مقاله اضافه خواهند شد.

2- داشتن یک جدول پایه که کل فایل‌ها در آن ذخیره شوند (روش‌های دوم و سوم)

  • متمرکز شدن کل فایل‌ها در یک جدول: بیشتر پروژه‌ها و یا برنامه نویسان (طبق تجربه‌ی بنده) یک جدول پایه را برای این منظور دوست دارند. به دلیل اینکه تمام اطلاعات یکجا باشد.
  • عدم آپلود چندین باره‌ی یک فایل: در این حالت می‌توان از یک فایل چندین بار در چند جای مختلف استفاده نمود و در فضای هاست صرفه جویی می‌شود. این روش مدیریت سختی دارد و نیازمند کوئری‌های بیشتری می‌باشد.
  • وجود فیلد‌های زیاد null در جدول: در این حالت ممکن است ردیف‌هایی با ستون‌های مقدار null در جدول زیاد شوند. فرض کنید دو فیلد در جدول attachment وجود دارند که فقط توسط جدول مقالات مورد استفاده قرار می‌گیرند و در بقیه‌ی جداول بدون استفاده می‌باشند.


از کدام روش استفاده کنیم؟

نمی توان پیشنهاد کرد که الزاما از کدامیک از روش‌های بالا باید استفاده کنیم؛ چون نیازمندهای‌های هر پروژه با هم متفات است و نمی‌توان نسخه‌ای خاص را برای همه تجویز کرد.

بازخوردهای دوره
تهیه کوئری بر روی ایندکس‌های Full Text Search
بنده در حال ساخت جستجویی برای وب سایتی هستم. این جستجو بر روی جداول کتاب، نویسنده، مترجم و انتشارات انجام میشه و در صورتی که کاربر قسمتی از نام کتاب و نام نویسنده را وارد کند جستجو بر روی این دو فیلد که از دو جدول متفاوت هستند انجام می‌شود.
مشکل اینجاست که از آنجایی که دستوارت FTS بر روی یک جدول عمل می‌کنند و با توجه به پیچیدگی جستجو، شما چه راهی را برای کوئری گرفتن از چندین جدول (که ممکن است یک کتاب چند نویسنده هم داشته باشد) پیشنهاد می‌کنید.
بنده در حال حاضر تمام این جداول را در یک View قرار داده و فیلدهای چندمقداری را با Concat بوسیله " ، " در یک فیلد جای داده‌ام.
ممنون از راهنماییتون
اشتراک‌ها
دریافت کتاب SignalR Programming in Microsoft ASP.NET انتشارات مایکروسافت
این کتاب یک راهنمای دقیق برای SignalR است؛ SignalR یک کتاب خانه‌ی جدید برای توسعه دهندگان ASP.NET است که روند توسعه‌ی برنامه‌های تحت وب بلادرنگ را آسان می‌کند. قابلیت بلادرنگی در وب، سرور را قادر می‌سازد تا محتویات مورد نظرش را به بدون وقفه در لحظه ای که کلاینت‌ها به آن متصل می‌شوند ارسال نماید. در این کتاب توسعه دهندگان Microsoft .NET که با HTML و JavaScript آشنایی دارند، به توانایی توسعه برنامه‌های بلادرنگ و ارتباطات نا متقارن تحت وب، دسکتاپ و گوشی‌های موبایل دست پیدا می‌کنند. 
دریافت کتاب SignalR Programming in Microsoft ASP.NET انتشارات مایکروسافت