مهدی سعیدی فر مهدی سعیدی فر
پروژه‌ها
پروژه سامانه برگزاری مسابقات ورزشی پیاده سازی شده به وسیله ASP.NET MVC و AngularJS
این سامانه به کمک فریمورک‌های ASP.NET MVC و AngularJS پیاده سازی شده است.

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

امکانات سامانه:

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


نحوه‌ی ورود به سیستم

برای ورود به مدیریت سامانه، از قسمت فوتر سایت بر روی "ورود همکاران" کلیک کنید.

ایمیل و کلمه عبور برای ورود به مدیریت سامانه

ایمیل: admin@gmail.com
کلمه عبور: 123admin123

ایمیل و کلمه عبور برای ورود به سامانه مسابقات

ایمیل: user@gmail.com
کلمه عبور: 123user123

نکته: سورس کد این پروژه را فقط از مخزن کد پروژه می‌توانید دریافت کنید.

 


‫۸ سال و ۱۱ ماه قبل، شنبه ۳۰ آبان ۱۳۹۴، ساعت ۰۴:۵۶
وحید نصیری وحید نصیری
مطالب دوره‌ها
بررسی Semantic Search و FTS Table-valued functions
Semantic Search جزو تازه‌های SQL Server 2012 است و مقدمات نصب و فعال سازی آن‌را در قسمت اول بررسی کردیم.
توابع Predicates مختص به FTS مانند Contains و Freetext، تنها ردیف‌های متناظر با جستجوی انجام شده را باز می‌گردانند و رتبه‌ای به نتایج جستجو اعمال نمی‌گردد. برای مثال، مشخص نیست اولین ردیف بازگشت داده شده بهترین تطابق را با جستجوی انجام شده دارد یا بدترین نتیجه‌ی ممکن است. برای رفع این مشکل FTS table-valued functions معرفی شده‌اند. حاصل این‌ها یک جدول با دو ستون است. ستون اول کلید متناظر با جدول تطابق یافته بوده و ستون دوم، Rank نام دارد که بیانگر میزان مفید بودن و درجه‌ی اعتبار ردیف بازگشت داده شده‌است.
Semantic Search نیز به کمک سه table-valued functions پیاده سازی می‌شود. همچنین باید دقت داشت که تمام زبان‌های پشتیبانی شده توسط FTS در حالت Semantic Search پشتیبانی نمی‌شوند. برای بررسی این مورد، دو کوئری ذیل را اجرا نمائید:
 -- Full text Languages
SELECT *
FROM sys.fulltext_languages
ORDER BY name;

-- Semantic Search Languages
SELECT *
FROM sys.fulltext_semantic_languages
ORDER BY name;
GO

بررسی table-valued functions مختص به FTS

دو متد ویژه‌ی CONTAINSTABLE و FREETEXTTABLE خروجی از نوع جدول دارند؛ با ستون‌هایی به نام‌های key و rank. اگر قسمت ایجاد کاتالوگ FTS و ایندکس آن‌را بخاطر داشته باشید، در حین ایجاد ایندکس FTS می‌بایستی KEY INDEX PK_Documents را نیز ذکر کرد. کاربرد آن در همین table-valued functions است.
مقدار rank، عددی است بین 0 و 1000 که هر چقدر مقدار آن بیشتر باشد، یعنی نتیجه‌ای نزدیک‌تر، به عبارت جستجو شده، یافت گردیده‌است. باید دقت داشت که این عدد فقط در زمینه‌ی یک کوئری معنا پیدا می‌کند و مقایسه‌ی rank دو کوئری مختلف با هم، بی‌معنا است.
عملکرد CONTAINSTABLE بسیار شبیه به متد Contains است با این تفاوت که قابلیت‌های بیشتری دارد. برای مثال در اینجا می‌توان برای قسمتی از جستجو، وزن و اهمیت بیشتری را قائل شد و این حالت تنها زمانی معنا پیدا می‌کند که خروجی جستجو، دارای rank باشد.
متد FREETEXTTABLE نیز بسیار شبیه به FREETEXT عمل کرده و نسبت به CONTAINSTABLE بسیار ساده‌تر است. برای نمونه امکان تعریف وزن، formsof، near و غیره در اینجا وجود ندارد. به علاوه عملگرهای منطقی مانند and و or نیز در اینجا کاربردی نداشته و صرفا یک noise word درنظر گرفته می‌شوند.


چند مثال جهت بررسی عملکرد دو متد CONTAINSTABLE و FREETEXTTABLE

استفاده از متد CONTAINSTABLE 
 -- Rank with CONTAINSTABLE
SELECT D.id, D.title, CT.[RANK], D.docexcerpt
FROM CONTAINSTABLE(dbo.Documents, docexcerpt,
N'data OR level') AS CT
 INNER JOIN dbo.Documents AS D
  ON CT.[KEY] = D.id
ORDER BY CT.[RANK] DESC;
چون متد CONTAINSTABLE خروجی از نوع table دارد، در قسمت from ذکر شده‌است.
این متد ابتدا نام جدول مورد بررسی را دریافت می‌کند. سپس ستونی که باید جستجو بر روی آن انجام شود و در ادامه عبارت جستجو شونده، مشخص می‌گردد. اگر این متد را به تنهایی اجرا کنیم:
 SELECT * FROM CONTAINSTABLE(dbo.Documents, docexcerpt, N'data OR level')
همانطور که عنوان شد، صرفا یک سری ردیف اشاره کننده به id و rank را بازگشت می‌دهد. به همین جهت join نوشته شده‌است تا بتوان رکوردهای اصلی را نیز در همینجا به همراه rank متناظر، نمایش داد.


استفاده از متد FREETEXTTABLE 

 -- Rank with FREETEXTTABLE
SELECT D.id, D.title, FT.[RANK], D.docexcerpt
FROM FREETEXTTABLE (dbo.Documents, docexcerpt,
N'data level') AS FT
 INNER JOIN dbo.Documents AS D
  ON FT.[KEY] = D.id
ORDER BY FT.[RANK] DESC;
کلیات عملکرد متد FREETEXTTABLE بسیار شبیه است به متد CONTAINSTABLE؛ با این تفاوت که ساده‌تر بوده و بسیاری از قابلیت‌های پیشرفته و سفارشی CONTAINSTABLE را به صورت خودکار و یکجا اعمال می‌کند. به همین جهت دقت آن، اندکی کمتر بوده و عمومی‌تر عمل می‌کند.
در اینجا اگر نیاز باشد تا تعداد نتایج را شبیه به کوئری‌های top n محدود نمود، می‌توان از پارامتر عددی بعدی که برای نمونه به 2 تنظیم شده‌است، استفاده کرد:
 -- Rank with FREETEXTTABLE and top_n_by_rank
SELECT D.id, D.title, FT.[RANK], D.docexcerpt
FROM FREETEXTTABLE (dbo.Documents, docexcerpt,
N'data level', 2) AS FT
 INNER JOIN dbo.Documents AS D
  ON FT.[KEY] = D.id
ORDER BY FT.[RANK] DESC;
در این کوئری تنها 2 ردیف بازگشت داده می‌شود.

تعیین وزن و اهمیت کلمات در حال جستجو 

 -- Weighted terms
SELECT D.id, D.title, CT.[RANK], D.docexcerpt
FROM CONTAINSTABLE
(dbo.Documents, docexcerpt,
N'ISABOUT(data weight(0.8), level weight(0.2))') AS CT
 INNER JOIN dbo.Documents AS D
  ON CT.[KEY] = D.id
ORDER BY CT.[RANK] DESC;
با استفاده از واژه کلیدی ISABOUT، امکان تعیین وزن، برای واژه‌های در حال جستجو ممکن می‌شوند. در این کوئری اهمیت واژه data بیشتر از اهمیت واژه level تعیین شده‌است.


انجام جستجو‌های Proximity 
 -- Proximity term
SELECT D.id, D.title, CT.[RANK]
FROM CONTAINSTABLE (dbo.Documents, doccontent,
N'NEAR((data, row), 30)') AS CT
 INNER JOIN dbo.Documents AS D
  ON CT.[KEY] = D.id
ORDER BY CT.[RANK] DESC;
GO
در اینجا مانند متد CONTAINS، امکان انجام جستجوهای Proximity نیز وجود دارد. برای مثال در کوئری فوق به دنبال رکوردهایی هستیم که در آن‌ها واژه‌های data و row وجود دارند، با فاصله‌ای کمتر از 30 کلمه.


بررسی Semantic Search key valued functions

متد SEMANTICKEYPHRASETABLE کار بازگشت واژه‌های کلیدی آنالیز شده توسط FTS را انجام داده و جدولی حاوی 4 ستون را باز می‌گرداند. این چهار ستون عبارتند از:
- column_id: شماره ستون واژه کلیدی یافت شده‌است. تفسیر آن نیاز به استفاده از تابع سیستمی COL_NAME دارد (مانند مثال زیر).
- document_key: متناظر است با کلید اصلی جدولی که بر روی آن کوئری گرفته می‌شود.
- keyphrase: همان واژه کلیدی است.
- score: رتبه‌ی واژه کلیدی است در بین سایر واژه‌هایی که بازگشت داده شده و عددی است بین صفر تا یک.

مثالی از آن‌را در ادامه ملاحظه می‌کنید:
 -- Top 100 semantic key phrases
SELECT TOP (100)
 D.id, D.title,
 SKT.column_id,
 COL_NAME(OBJECT_ID(N'dbo.Documents'), SKT.column_id) AS column_name,
 SKT.document_key,
 SKT.keyphrase, SKT.score
FROM SEMANTICKEYPHRASETABLE
(dbo.Documents, doccontent) AS SKT
 INNER JOIN dbo.Documents AS D
  ON SKT.document_key = D.id
ORDER BY SKT.score DESC;


در متد جدولی SEMANTICKEYPHRASETABLE، ابتدا جدول مورد نظر و سپس ستونی که نیاز است واژه‌های کلیدی آنالیز شده‌ی آن بازگشت داده شوند، قید می‌گردند. document_key آن به تنهایی شاید مفید نباشد. به همین جهت join شده‌است به جدول اصلی، تا بتوان رکوردهای متناظر را نیز بهتر تشخیص داد.
به این ترتیب مهم‌ترین واژه‌های کلیدی ستون doccontent را به همراه درجه‌ی اهمیت و رتبه‌ی آن‌ها، می‌توان گزارش گرفت.


متد SEMANTICSIMILARITYTABLE برای یافتن سندهای مشابه با یک سند مشخص بکار می‌روند؛ چیزی شبیه به گزارش «مقالات مشابه مطلب جاری» در بسیاری از سایت‌های ارائه‌ی محتوا. ستون‌های خروجی آن عبارتند از:
- source_column_id: شماره ستون منبع انجام کوئری.
- matched_column_id: شماره ستون سند مشابه یافت شده.
- matched_document_key: متناظر است با کلید اصلی جدولی که بر روی آن کوئری گرفته می‌شود.
- score: رتبه‌ی نسبی سند مشابه یافت شده.

 -- Documents that are similar to document 1
SELECT S.source_document_title,
 SST.matched_document_key,
 D.title AS matched_document_title,
 SST.score
FROM
 (SEMANTICSIMILARITYTABLE
  (dbo.Documents, doccontent, 1) AS SST
  INNER JOIN dbo.Documents AS D
ON SST.matched_document_key = D.id)
 CROSS JOIN
  (SELECT title FROM dbo.Documents WHERE id=1)
AS S(source_document_title)
ORDER BY SST.score DESC;



در این کوئری، اسناد مشابه با سند شماره 1 یافت شده‌اند. مبنای جستجو نیز ستون doccontent، جدول dbo.Documents است. از join بر روی matched_document_key و id جدول اصلی، مشخصات سند یافت شده را می‌توان استخراج کرد. کار CROSS JOIN تعریف شده، صرفا افزودن یک ستون مشخص به نتیجه‌ی خروجی کوئری است.
همانطور که در تصویر مشخص است، سند شماره 4 بسیار شبیه است به سند شماره 1. در ادامه قصد داریم بررسی کنیم که علت این شباهت چه بوده‌است؟


متد SEMANTICSIMILARITYDETAILSTABLE واژه‌های کلیدی مهم مشترک بین دو سند را بازگشت می‌دهد (سند منبع و سند مقصد). به این ترتیب می‌توان دریافت، چه واژه‌های کلیدی سبب شده‌اند تا این دو سند به هم شبیه باشند. ستون‌های خروجی آن عبارتند از:
- keyphrase: واژه‌ی کلیدی
- score: رتبه‌ی نسبی واژه‌ی کلیدی

 -- Key phrases that are common across two documents
SELECT SSDT.keyphrase, SSDT.score
FROM SEMANTICSIMILARITYDETAILSTABLE
(dbo.Documents, doccontent, 1,
doccontent, 4) AS SSDT
ORDER BY SSDT.score DESC;


در کوئری فوق قصد داریم بررسی کنیم چه واژه‌های کلیدی، سبب مشابهت سندهای شماره 1 و 4 شده‌اند و بین آن‌ها مشترک می‌باشند.
‫۱۰ سال و ۸ ماه قبل، شنبه ۱۷ اسفند ۱۳۹۲، ساعت ۰۵:۰۶
علی رضایی علی رضایی
بازخوردهای دوره
شروع به کار با RavenDB
با سلام و احترام
در انتهای بحث فرمودید «نکته جالبی که در اینجا وجود دارد، عدم نیاز به join نویسی برای دریافت اطلاعات وابسته به یک شیء است». با توجه به این مطلب من دقیقا متوجه نشدم در مسئله زیر چه باید کرد:
هر answer و question توسط By مشخص میشود توسط چه کسی ارسال شده (مثلاً : "users/Vahid":"By")، و در سند users اطلاعات کامل هر کاربر مثل نام کاریری، ایمیل، آدرس و شماره تماس و... در زمان ثبت نام ذخیره شده است. سوال: اگر لازم باشد به ازای هر سوال یا جواب ایمیل و شماره تماس فرستنده را هم به کاربر نهایی نشان دهیم، باید در زمان ارسال سوال یا جواب ابتدا کاربر را با استفاده از By در users یافته و ایمیل و شماره تماس وی را خوانده و در سند آن سوال یا جواب ذخیره کنیم؛ یا باید هر زمان که سوال یا جوابی ارسال شد فقط نام کاربری را ثبت کنیم و در زمان نمایش سوال‌ها و جواب‌ها به کاربر مشحصات فرستنده را از users خوانده و همراه با خصوصیات دیگر به کاربر نشان دهیم، که این مورد آخر همان بانک‌های اطلاعاتی رابطه ای است.
‫۹ سال و ۹ ماه قبل، جمعه ۲۶ دی ۱۳۹۳، ساعت ۲۳:۴۷
مهمان مهمان
نظرات اشتراک‌ها
روش دیگری برای تمیزسازی HTML و مقابله با XSS
سلام آقای نصیری بنده اینجا که توضیحی مشاهده نمیکنم.ممنون میشم برای تمیزکاری کدهای html راهی بهمون معرفی کنید بنده خودم تویه سایتم از getsafehtmlfragment استفاده کردم ولی مشکل اینجاست که تویه نسخه جدید این متد تمام تگ‌ها رو حذف میکنه از جمله تگ‌های html و اینجاست که برای گرفتن امن اطلاعات یک ادیتور با مشکل مواجه میشیم.فکر کنم باید از htmlagilitypack استفاده بشه که نحوه کار کردن باهاش رو بلد نیستم بنده یه سوال دیگه هم دارم ممنون میشم تویه این پست توضیح بدهید برای نمایش امن اطلاعات یک ادیتور باید چیکار کنیم وقتی از htmlencode استفاده میکنم تمام تگ‌ها از جمله تگ‌های html رو نشون میده باید چیکار کنم شما که زحمت کشید یه توضیح کامل بدید که همگی استفاده کنیم ممنون از شما
‫۱۱ سال و ۱۰ ماه قبل، شنبه ۳۰ دی ۱۳۹۱، ساعت ۱۳:۰۹
نصری نصری
نظرات مطالب
پیاده سازی برنامه‌های چند مستاجری در ASP.NET Core
جدای از استراتژی‌های مختلفی که برای شناسایی هر مستاجر در اینگونه وب اپلیکیشن‌ها اعمال میشود، سوال اینجاست که: برای سیستم‌های چند مستاجری Saas (با دیتابیس‌های جداگانه)، طبیعتاً  ما یک سایت جداگانه هم روی هاستی جداگانه برای بخش نمایش و فروش پلن‌های مختلف به مستاجران خواهیم داشت که مستاجر جدید ابتدا باید مشخصات شرکت/موسسه خود را در فیلدها درج کرده و سپس به مرحله‌ی نهایی و آخر که (پرداخت هزینه‌ی پلن مورد نظر خود میباشد) هدایت شود.  حال با فرض اینکه تمام مراحل تا اتمام پرداخت هزینه‌ی مربوطه درست انجام شود، آیا اطلاعات ثبت نامی و سوابق پرداختی و عملکرد مستاجران باید در دیتابیسی جداگانه مدیریت و ذخیره شوند؟؟ چرا که هدف از این پرسش، داشتن مجموعه اطلاعات جامعی از مشخصات ریز و درشت کلیه مستاجران جهت ارائه‌ی داشبوردی جامع به توسعه دهندگان آن در پس زمینه میباشد.
‫۱ سال قبل، سه‌شنبه ۱۱ مهر ۱۴۰۲، ساعت ۰۰:۴۹