جواد حاجیان نژاد جواد حاجیان نژاد
نظرات مطالب
استفاده از Full text search توسط Entity Framework
چند نکته بسیار مهم درباره قابلت  Full Text Search که دوستان باید مد نظر داشته باشند عبارتست : 
1- ابتدا باید در هنگام نصب این قابلیت را در SQL Server فعال کرده باشید 

2- برای اینکه بتوان بر روی ستون‌های مورد نظر Full text Serach زد باید index‌های لازم و همچنین کاتولوگ‌های لازم را تعریف نمود.

//ایجاد کاتالوگ 
 use AdventureWorks
 create fulltext catalog FullTextCatalog as default

 select *
 from sys.fulltext_catalogs

//تعریف ایندکس بر روی ستون  مورد نظر
 create fulltext index on Production.ProductDescription(Description)
 key index PK_ProductDescription_ProductDescriptionID

3- توجه داشته باشید برای حجم داده‌های کم قابلیت Full text Search بسیار کند و زمان بر‌تر از جست و جوهای پایه نظیر استفاده از Like می‌باشد و زمانی که حجم داده‌ها زیاد می‌باشد باید از قابلیت  Full text Search استفاده شود

4- خروجی جست وجوی Full Text Search و جست و جوی معمولی برای داده‌های زیاد یکسان نمی‌باشد ، کافی است در یک دیتا بیس با حجم بالای داده‌ها جست و جو را با هر دو روش انجام دهید ، آن وقت خواهید دید که جست و جوی سنتی (نظیر استفاده از دستور  LIKE) بسییار دقیق‌تر می‌باشد و تمامی اطلاعات خواسته شده را درست بر خواهد گرداند، امام با استفاده از Full Text Search این اطلاعات کامل نمی‌باشد! کافی است خودتان امتحان کنید 

‫۸ سال و ۱۲ ماه قبل، جمعه ۸ آبان ۱۳۹۴، ساعت ۱۸:۰۹
وحید نصیری وحید نصیری
مطالب
محدود کردن دسترسی به اس کیوال سرور بر اساس IP

عموما محدود کردن دسترسی بر اساس IP بهتر است بر اساس راه حل‌هایی مانند فایروال، IPSec و یا RRAS IP Filter صورت گیرد که جزو بهینه‌ترین و امن‌ترین راه حل‌های ممکن هستند.
در ادامه قصد داریم این محدودیت را با استفاده از امکانات خود اس کیوال سرور انجام دهیم (بلاک کردن کاربران بر اساس IP های غیرمجاز). مواردی که در ادامه ذکر خواهند شد در مورد اس کیوال سرور 2005 ، سرویس پک 2 به بعد و یا اس کیوال سرور 2008 صادق است.
اس کیوال سرور این قابلیت را دارد که می‌توان بر روی کلیه لاگین‌های صورت گرفته در سطح سرور تریگر تعریف کرد. به این صورت می‌توان تمامی لاگین‌ها را برای مثال لاگ کرد (جهت بررسی مسایل امنیتی) و یا می‌توان هر لاگینی را که صلاح ندانستیم rollback نمائیم (ایجاد محدودیت روی لاگین در سطح سرور).

لاگ کردن کلیه لاگین‌های صورت گرفته به سرور

ایجاد جدولی برای ذخیره سازی اطلاعات لاگین‌ها:

USE [master]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[Logging](
 [id] [int] IDENTITY(1,1) NOT NULL,
 [LogonTime] [datetime] NULL,
 [LoginName] [nvarchar](max) NULL,
 [ClientHost] [varchar](50) NULL,
 [LoginType] [varchar](100) NULL,
 [AppName] [nvarchar](500) NULL,
 [FullLog] [xml] NULL,
CONSTRAINT [PK_IP_Log] PRIMARY KEY CLUSTERED
(
 [id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [dbo].[Logging] ADD  CONSTRAINT [DF_IP_Log_LogonTime]  DEFAULT (getdate()) FOR [LogonTime]
GO

در ادامه یک تریگر لاگین را جهت ذخیره سازی اطلاعات کلیه لاگین‌ها به سرور ایجاد می‌نمائیم:
USE [master]
GO

CREATE TRIGGER LogonTrigger
ON ALL SERVER
FOR LOGON
AS
BEGIN
   DECLARE @data XML   
   SET @data = EVENTDATA()
  
   INSERT INTO [Logging]
     (
       [LoginName],
       [ClientHost],
       [LoginType],
       [AppName],
       [FullLog]
     )
   VALUES
     (
       @data.value('(/EVENT_INSTANCE/LoginName)[1]', 'nvarchar(max)'),
       @data.value('(/EVENT_INSTANCE/ClientHost)[1]', 'varchar(50)'),
       @data.value('(/EVENT_INSTANCE/LoginType)[1]', 'varchar(100)'),
       APP_NAME(),
       @data
     )
END
اکنون برای مثال از آخرین 100 لاگین انجام شده، به صورت زیر می‌توان گزارشگیری کرد:

SELECT TOP 100 *  FROM [master].[dbo].[Logging] ORDER BY id desc
و بدیهی است در تریگر فوق می‌توان روی هر کدام از آیتم‌های دریافتی مانند ClientHost و غیره فیلتر ایجاد کرد و تنها موارد مورد نظر را ثبت نمود.

محدود کردن کاربران بر اساس IP

ClientHost ایی که در رخ‌داد لاگین فوق بازگشت داده می‌شود همان IP کاربر راه دور است. برای فیلتر کردن IP های غیرمجاز، ابتدا در دیتابیس مستر یک جدول برای ذخیره سازی IP های مجاز ایجاد می‌کنیم و IP های کلیه کلاینت‌های معتبر خود را در آن وارد می‌کنیم:

USE [master]
GO
CREATE TABLE [IP_RESTRICTION](
 [ValidIP] [varchar](15) NOT NULL,
CONSTRAINT [PK_IP_RESTRICTION] PRIMARY KEY CLUSTERED
(
 [ValidIP] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

سپس تریگر لاگین ما برای منع کاربران غیرمجاز بر اساس IP ، به صورت زیر خواهد بود:

USE [master]
GO

CREATE TRIGGER [LOGIN_IP_RESTRICTION]
     
ON ALL SERVER
FOR LOGON
AS
BEGIN           
   DECLARE @host NVARCHAR(255);        
   SET @host = EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'nvarchar(max)');
                         
   IF (
          NOT EXISTS(
              SELECT *
              FROM   MASTER.dbo.IP_RESTRICTION                       
              WHERE  ValidIP = @host
          )
      )               
   BEGIN
          ROLLBACK;               
   END
END;
اخطار مهم!
تریگر فوق خطرناک است! ممکن است خودتان هم دیگر نتوانید لاگین کنید!! (حتی با اکانت ادمین)
بنابراین قبل از لاگین حتما IP لوکال و یا ClientHost لوکال را هم وارد کنید.
اگر گیر افتادید به صورت زیر می‌شود رفع مشکل کرد:
تنها حالتی که تریگر لاگین را فعال نمی‌کند Dedicated Administrator Connection است یا DAC هم به آن گفته می‌شود. به صورت پیش فرض برای ایجاد این اتصال اختصاصی باید به کامپیوتری که اس کیوال سرور بر روی آن نصب است به صورت لوکال لاگین کرد و سپس در خط فرمان دستور زیر را صادر کنید (حرف A آن باید بزرگ باشد):

C:\>sqlcmd -A -d master -q "insert into IP_RESTRICTION(validip) values('<local machine>')"
به این صورت local machine به جدول IP های مجاز اضافه شده و می‌توانید لاگین کنید!
این نوع تریگرها در قسمت server objects در management studio ظاهر می‌شوند.

‫۱۵ سال و ۷ ماه قبل، جمعه ۱۱ اردیبهشت ۱۳۸۸، ساعت ۰۱:۳۹
سیروان عفیفی سیروان عفیفی
مطالب
سری بررسی SQL Smell در EF Core - استفاده از مدل Entity Attribute Value - بخش اول
یکی از چالش‌های دیتابیس‌های رابطه‌ایی، ذخیره‌سازی داده‌هایی با ساختار داینامیک است. در حالت عادی، یک جدول مجموعه‌ایی از موجودیت‌ها است. هر موجودیت نیز شامل یکسری ویژگی‌های (Attributes) مشخص می‌باشد. اما شرایطی را در نظر بگیرید که تعداد این ویژگی‌ها به صورت مشخص و ثابتی نباشد؛ یعنی برای هر موجودیت، ویژگی‌های متفاوتی داشته باشیم. یک روش پیاده‌سازی اینچنین سناریوهایی، استفاده از مدلی با نام Entity Attribute Value است. در این روش ستون‌های داینامیک را درون یک جدول جنریک تعریف خواهیم کرد. به عنوان مثال برای ذخیره‌سازی اطلاعات اشخاص، در حالت نرمال، یک جدول با ساختار مشخصی خواهیم داشت: 
create table Employees
(
   Id int auto_increment
   primary key,
   FirstName text null,
   LastName text null,
   DateOfBirth timestamp not null
);
تعریف جدول فوق نیز در Entity Framework به اینصورت خواهد بود:
public class Employee
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTimeOffset DateOfBirth { get; set; }
}

public class MyDbContext : DbContext
{
    public DbSet<Employee> Employees { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseMySQL(_configuration.GetConnectionString("DataConnection"));
    }
}


اما در مدل EAV، خواص داینامیک را به درون جدول دومی منتقل خواهیم کرد: 

create table EmployeeEav
(
   Id int auto_increment
   primary key
);

create table EmployeeAttributes
(
  Id int auto_increment
  primary key,
  EmployeeId int not null,
  AttributeName text null,
  AttributeValue text null,
  constraint FK_EmployeeAttributes_EmployeeEav_EmployeeId
  foreign key (EmployeeId) references EmployeeEav (Id)
  on delete cascade
);

create index IX_EmployeeAttributes_EmployeeId
on EmployeeAttributes (EmployeeId);

تعریف جداول فوق نیز در Entity Framework به اینصورت خواهند بود:

public class EmployeeEav
{
    public int Id { get; set; }
    public virtual ICollection<EmployeeAttribute> Attributes { get; set; }
}

public class EmployeeAttribute
{
    public int Id { get; set; }
    public virtual EmployeeEav Employee { get; set; }
    public int EmployeeId { get; set; }
    public string AttributeName { get; set; }
    public string AttributeValue { get; set; }
}

public class MyDbContext : DbContext
{

    public DbSet<EmployeeEav> EmployeeEav { get; set; }
    public DbSet<EmployeeAttribute> EmployeeAttributes { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseMySQL(_configuration.GetConnectionString("DataConnection"));
    }
}



درون این جدول دوم، سه فیلد اصلی داریم: یکی به عنوان Entity که در اینجا یک ارجاع را به جدول EmployeeEav دارد. یک فیلد به عنوان Attribute که برای تعیین نام ویژگی داینامیک استفاده می‌شود و در نهایت یک Value که برای ذخیره‌سازی مقدار ویژگی مورد استفاده قرار میگیرد. بنابراین به این نوع طراحی، Entity Attribute Value گفته می‌شود. مزیت اصلی این روش، انعطاف زیاد آن است در واقع می‌توانیم N تعداد ویژگی را برای Entity موردنظرمان داشته باشیم. اما این روش یک SQL Smell است و اشکالات زیادی را به همراه دارد:

  • کوئری گرفتن در این روش سخت است
یکی از مشکلات اصلی این روش این است امکان کوئری گرفتن از جدول ویژگی‌ها را سخت میکند. در واقع این روش به store everything, query nothing معروف است. مثلاً فرض کنید می‌خواهیم لیست کارمندانی را که تاریخ تولدشان ۲۵ سال پیش است، واکشی کنیم. در حالت عادی با تعداد ستون ثابت می‌توانیم به راحتی اینکار را انجام دهیم: 
SELECT `e`.`Id`, `e`.`DateOfBirth`, `e`.`FirstName`, `e`.`LastName`
FROM `Employees` AS `e`
WHERE `e`.`DateOfBirth` > @__endDate_0
کوئری LINQ کد فوق اینچنین شکلی خواهد داشت: 
var endDate = DateTimeOffset.Now.AddYears(Convert.ToInt32(-25));
var normalTypes = dbContext.Employees.Where(x => x.DateOfBirth > endDate).ToList();
اما در مدل EAV نوشتن کوئری فوق خیلی سخت‌تر خواهد بود:  
SELECT MAX(CASE AttributeName
               WHEN 'FirstName'
                   THEN AttributeValue
    END)        AS FirstName,
       MAX(CASE AttributeName
               WHEN 'LastName'
                   THEN AttributeValue
           END) AS LastName,
       MAX(CASE AttributeName
               WHEN 'DateOfBirth'
                   THEN AttributeValue
           END) AS DateOfBirth
FROM efcoresample.EmployeeAttributes
WHERE EmployeeId IN (SELECT EmployeeId
                     FROM efcoresample.EmployeeAttributes
                     WHERE AttributeName = 'DateOfBirth'
                       AND AttributeValue > DATE_SUB(CURRENT_DATE(), INTERVAL 25 YEAR))
  AND AttributeName IN ('FirstName', 'LastName', 'DateOfBirth')
GROUP BY EmployeeId;
همچنین کوئری LINQ آن نیز به همان اندازه سخت میباشد:  
string[] columnNames = {"FirstName", "LastName", "DateOfBirth"};
var employees = dbContext.EmployeeAttributes
    .Where(x => 
                dbContext.EmployeeAttributes
                    .Where(i => i.AttributeName == "DateOfBirth")
                    .Select(eId => eId.EmployeeId).Contains(x.EmployeeId) &&
                columnNames.Contains(x.AttributeName))
    .GroupBy(x => x.EmployeeId)
    .Select(g => new
    {
        FirstName = g.Max(f => f.AttributeName == "FirstName" ? f.AttributeValue : ""),
        LastName = g.Max(f => f.AttributeName == "LastName"? f.AttributeValue : ""),
        DateOfBirth = g.Max(f => f.AttributeName == "DateOfBirth"? f.AttributeValue : ""),
        Id = g.Key
    })
    .ToList()
    .Where(x => DateTime.ParseExact(x.DateOfBirth, "yyyy-MM-dd", CultureInfo.InvariantCulture) > DateTime.Now.AddYears(-25));

  • امکان تعریف فیلدهای اجباری را نخواهیم داشت
در حالت نرمال و ساختاریافته، برای هرکدام از فیلدها می‌توانیم الزامی و یا اختیاری بودن آنها را به راحتی با NOT NULL تعیین کنیم. اما در مدل EAV این امکان را نخواهیم داشت. 

  • امکان تعیین نوع ستون‌ها را نخواهیم داشت
در حالت نرمال به راحتی می‌توانیم نوع فیلد موردنظر را تعیین کنیم. اما در مدل EAV به دلیل ماهیت داینامیک ستون‌ها، این امکان را نداریم. ستون AttributeValue همزمان ممکن است تاریخ، عددی، اعشاری و… باشد در نتیجه چون از ورودی مطمئن نیستیم، مجبوریم تایپ آن را به رشته تنظیم کنیم. 

  • امکان تعریف کلیدهای خارجی را نخواهیم داشت
در مدل EAV نمی‌توانیم صحت دیتا را تضمین کنیم؛ زیرا امکان تعریف کلید خارجی را نخواهیم داشت.

بنابراین بهتر است تا حد امکان از مدل EAV استفاده نشود؛ مگر اینکه در شرایطی خاص، مجبور به استفاده‌ی از آن باشید. به عنوان مثال برنامه‌ی شما قرار است قابلیت ایمپورت هر نوع فایل CSV را داشته باشد. هر فایل هم ممکن است به تعداد نامشخصی، یکسری ستون را داشته باشد. در این شرایط می‌توانید با در نظر گرفتن موارد فوق، از مدل مطرح شده استفاده کنید.
‫۴ سال و ۲ ماه قبل، دوشنبه ۱۳ مرداد ۱۳۹۹، ساعت ۰۱:۲۰
وحید نصیری وحید نصیری
نظرات مطالب
انجام کارهای زمانبندی شده در برنامه‌های ASP.NET توسط DNT Scheduler
- به اندازه کافی در نظرات این بحث در مورد زنده نگه داشتن یک برنامه ASP.NET بحث شده. کمی وقت بگذارید و آن‌ها را مطالعه کنید.
+ اگر برنامه مالی است، احتمالا دسترسی کاملی به سرور و همچنین SQL Server (اگر با آن کار می‌کنید) دارید. در این حالت برای به روز رسانی زمانبندی شده‌ی چند رکورد شاید بهتر باشد از سرویس معروف و همیشه در حال اجرای SQL Server agent استفاده کنید. در اینجا نیز می‌شود یک job را که متشکل از دستورات T-SQL است، در فواصل زمانی مشخصی اجرا کرد.
‫۱۰ سال و ۵ ماه قبل، سه‌شنبه ۲۰ خرداد ۱۳۹۳، ساعت ۰۴:۴۹
وحید نصیری وحید نصیری
مطالب
جستجوی غیر حساس به بزرگی و کوچکی حروف در SQLite توسط EF-Core
اگر پیشتر با SQL Server کار کرده باشید، حالت پیش‌فرض حساس بودن جستجوی SQLite به بزرگی و کوچکی حروف را انتظار نخواهید داشت؛ تا زمانیکه هنگام لاگین، اکانت Admin بتواند وارد سیستم شود و اکانت admin خیر. در این مطلب نحوه‌ی انجام تنظیمات مرتبط با جستجوی غیرحساس به بزرگی و کوچکی حروف را در SQLite و EF-Core، بررسی خواهیم کرد.


Collations و حساسیت به بزرگی و کوچکی حروف

پردازش متون در بانک‌های اطلاعاتی پیچیده‌است و عموما فراتر است از انتظارات ساده‌ی اولیه، خصوصا اینکه بانک‌های اطلاعاتی متفاوت، روش‌های متفاوتی را هم در این زمینه بکار می‌گیرند. برای مثال بانک‌های اطلاعاتی مانند SQLite و PostgreSQL به صورت پیش‌فرض به بزرگی و کوچکی حروف حساس هستند، اما بانک‌هایی مانند SQL Server و MySQL خیر. همچنین این حساسیت، بر روی کارآیی جستجو نیز بسیار تاثیر گذار است. برای مثال می‌توان از متدهایی مانند string.ToLower برای انجام جستجوهای غیرحساس به بزرگی و کوچکی حروف استفاده کرد، اما بکارگیری آن‌ها بلافاصله استفاده‌ی از ایندکس‌ها را غیرفعال می‌کنند و سبب انجام جستجوهایی بسیار کند خواهند شد.

برای مواجه شدن با یک چنین حالت‌هایی بدون افت کارآیی برنامه، مفهوم پایه‌ای به نام collation در بانک‌های اطلاعاتی ارائه شده‌است که مشخص می‌کند مقادیر رشته‌ای چگونه باید مرتب شده یا مقایسه شوند. برای مثال یک collation غیرحساس به بزرگی و کوچکی حروف، در حین مقایسه‌ی رشته‌ها، به بزرگی و کوچکی حروف بکار گرفته شده‌ی در عبارت اهمیتی نمی‌دهد. همچنین باید دقت داشت که یک چنین مقایسه‌ای بسته به فرهنگ بکار گرفته شده، می‌توان متفاوت باشد؛ برای مثال در زبان ترکی، i و I حروف متفاوتی هستند و نباید در حین مقایسه‌ی غیرحساس به بزرگی و کوچکی حروف، یکی در نظر گرفته شوند. به همین جهت تعداد قابل ملاحظه‌ای case-insensitive collations از پیش تعریف شده، بسته به فرهنگ‌های مختلف وجود دارند؛ نمونه‌ی دیگر آن فرهنگ آلمانی است که در آن عموما ä و ae را یکسان درنظر می‌گیرند. به علاوه collation بر روی نحوه‌ی مرتب سازی حروف نیز تاثیر دارد؛ برای مثال در فرهنگ آلمانی، ä پس از a قرار می‌گیرد، اما در فرهنگ سوئدی در انتهای حروف الفباء واقع شده‌است.

تمام پردازش‌های متنی در بانک‌های اطلاعاتی (چه به صورت صریح و یا ضمنی) از collations استفاده می‌کنند و نام آن‌ها از هر بانک اطلاعاتی به بانک اطلاعاتی دیگری متفاوت است. عموما می‌توان این collations را در سطح کل بانک اطلاعاتی و یا در سطح یک ستون مشخص از آن و یا حتی در سطح یک کوئری مشخص، تعیین کرد.


روش تعیین collation در سطح بانک اطلاعاتی

در اغلب بانک‌های اطلاعاتی، یک collation پیش‌فرض، در سطح کل آن‌ها تعریف شده‌است و بر روی تمام پردازش‌های متنی و تمام ستون‌های جداول تاثیرگذار است. برای مثال حالت پیش‌فرض collation در SQL Server (اگر هیچ تنظیم پیش‌فرض دیگری در حین تعریف بانک اطلاعاتی وجود نداشته باشد) مقدار SQL_Latin1_General_CP1_CI_AS است. این مقدار یک collation غیرحساس به بزرگی و کوچکی حروف است. مقدار CI آن به معنای case-insensitive و AS آن مخفف accent-sensitive (حساس به لهجه) است.
از زمان EF-Core 5x، امکان کار با collations و تعیین آن‌ها نیز میسر شده‌است. برای مثال برای تعیین یک چنین collation ای در سطح بانک اطلاعاتی می‌توان به صورت زیر در متد OnModelCreating عمل کرد:
modelBuilder.UseCollation("SQL_Latin1_General_CP1_CS_AS");
البته بهتر است یک چنین تنظیماتی را از ابتدای کار و پیش از تعریف و ایجاد بانک اطلاعاتی درنظر داشت؛ چون تغییر collation پس از ایجاد بانک اطلاعاتی، تداخلات زیادی را ایجاد می‌کند. برای مثال SQL Server حتی اجازه‌ی join دو جدول با collation متفاوت را نمی‌دهد؛ هرچند راه‌حل‌هایی برای آن وجود دارد اما بهتر است این مقدار یکبار و آن هم در ابتدای کار تعیین شود.


روش تعیین collation در سطح جداول بانک اطلاعاتی

Collations را همچنین می‌توان در سطح جداول نیز مشخص کرد تا بتوان در صورت نیاز، collation پیش‌فرض بانک اطلاعاتی را بازنویسی نمود. برای مثال شاید نیاز داشته باشید جداولی case-insensitive و تعدادی دیگر case-sensitive باشند.
در EF-Core 5x به بعد، روش انجام اینکار به صورت زیر است:
modelBuilder.Entity<Customer>().Property(c => c.Name)
   .UseCollation("SQL_Latin1_General_CP1_CI_AS");
در اینجا collation ستون Name جدول Customer، به صورت صریحی مشخص شده‌است.


روش تعیین پویای collation در سطح کوئری‌های بانک اطلاعاتی

یک جدول می‌تواند collation پیش‌فرضی داشته باشد، اما در حین کوئری گرفتن، collation آن‌را به صورت موقت و پویا تغییر داد. برای مثال بجای استفاده از متد ToLower که سبب می‌شود از ایندکس‌ها استفاده نشود، می‌توان از collation خاصی در حین کوئری گرفتن استفاده کرد:
var customers = context.Customers
   .Where(c => EF.Functions.Collate(c.Name, "SQL_Latin1_General_CP1_CS_AS") == "John").ToList();
البته باید دقت داشت که تعیین collation در این حالت نیز سبب می‌شود تا از ایندکس‌ها استفاده نشود. از این جهت که ایندکس‌ها به صورت پیش‌فرض بر اساس collation یک ستون یا جدول تهیه می‌شوند. هرچند بانک اطلاعاتی‌هایی مانند PostgreSQL, Sqlite امکان تعیین collation را در حین تهیه‌ی ایندکس‌ها نیز میسر می‌کنند. برای مثال می‌توان ایندکس‌های حساس و غیر حساس به بزرگی و کوچکی حروف را در این بانک‌های اطلاعاتی، به صورت جداگانه‌ای تعریف کرد تا در صورت نیاز، از آن‌ها استفاده شود.

یک نکته: هر چند کوئری‌های سمت دات نت به صورت پیش‌فرض حساس به بزرگی و کوچکی حروف هستند (مانند s1 == s2)، اما EF-Core هیچ تلاشی را برای انجام یک کوئری case-sensitive در سمت بانک اطلاعاتی انجام نخواهد داد و == سی شارپ به صورت مستقیمی به تساوی SQL ترجمه می‌شود که بسته به collation جاری، می‌تواند یا حتی نمی‌تواند حساس به بزرگی و کوچکی حروف باشد. بنابراین حالت پیش‌فرض کوئری‌های EF-Core استفاده از collation پیش‌فرض ستون‌ها است. هرچند متدهایی مانند string.Equals امکان مقایسه‌ی غیرحساس به بزرگی و کوچکی حروف را در دات نت میسر می‌کنند (چون به همراه پارامتر StringComparison هستند)، اما EF-Core سعی در ترجمه‌ی آن‌ها به SQL نخواهد کرد و تعیین صریح collation توسط متد EF.Functions.Collate به شما واگذار شد‌ه‌است.
 

تعیین collation غیرحساس به بزرگی و کوچکی حروف در SQLite، توسط EF-Core

با توجه به توضیحات فوق، متد زیر، collation ویژه‌ی nocase را که در SQLite به معنای collation غیرحساس به بزرگی و کوچکی حروف است، به کل بانک اطلاعاتی و همچنین تمام ستون‌های رشته‌ای آن به صورت خودکار اعمال می‌کند:
public static void SetCaseInsensitiveSearchesForSQLite(this ModelBuilder modelBuilder)
{
    if (modelBuilder == null)
    {
        throw new ArgumentNullException(nameof(modelBuilder));
    }

    modelBuilder.UseCollation("NOCASE");
    foreach (var property in modelBuilder.Model.GetEntityTypes()
                                            .SelectMany(t => t.GetProperties())
                                            .Where(p => p.ClrType == typeof(string)))
    {
        property.SetCollation("NOCASE");
    }
}
سپس روش استفاده‌ی از آن به صورت زیر خواهد بود:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    if (modelBuilder == null)
    {
        throw new ArgumentNullException(nameof(modelBuilder));
    }

    modelBuilder.SetCaseInsensitiveSearchesForSQLite();
}
‫۲ سال و ۸ ماه قبل، یکشنبه ۲۶ دی ۱۴۰۰، ساعت ۱۵:۵۵
مهمان مهمان
بازخوردهای پروژه‌ها
ارسال پارامترهای اختیاری به دستور Sql و مشکل با دستور is null
با سلام
برای تهیه گزارشی به صورت پویا و با چندین پارامتر اختیاری (ارسال پارامتر با مقدار null) همچنین query تولید شده است.
Select [VoucherRows].[Description] AS [Description],[VoucherRows].[Creditor] AS [Creditor],[VoucherRows].[Debtor] AS [Debtor],[Vouchers].[Number] AS [Number],[Vouchers].[SubmitDate] AS [SubmitDate] 
From [VoucherRows] AS [VoucherRows],[Vouchers] AS [Vouchers] 
 Where [VoucherRows].[VoucherId] IS Null OR  [Vouchers].[Id]  =  [VoucherRows].[VoucherId]  
And @p1 IS Null OR  [Vouchers].[Number]  >=  @p1  
And @p2 IS Null OR  [Vouchers].[Number]  <=  @p2  And @p3 IS Null OR  [Vouchers].[Description]  Like  @p3   
 Order By [Vouchers].[SubmitDate] DESC,[Vouchers].[Number] ASC
و هنگام اجرای خطای 
//The specified argument value for the function is not valid. [ Argument # = 1,Name of function(if known) = isnull ]
را دارم. پس از جستجو این فروم پیشنهاد تغییر DbType  به  SqlDbType را داده است،
 آیا این راه حل با توجه به استفاده از   GenericDataReader و مدنظر بودن عمومیت آن در تضاد نیست؟
اگه این راه حل درسته باید کد داخل کتابخانه pdfreport تغییر کند؟
‫۱۰ سال و ۶ ماه قبل، چهارشنبه ۲۴ اردیبهشت ۱۳۹۳، ساعت ۱۵:۳۰
رضا منصوری رضا منصوری
اشتراک‌ها
پیاده سازی معماری میکروسرویس در دات نت

پیاده سازی معماری میکروسرویس در دات نت با استفاده از ابزار های

Ocelot For Api Getway

RabbitMQ For Message Broker

JWT Token For Authentication And Authorization

SQL Server And MongoDB For Databases

ASP Core Web Api For Our Rest Api And Swagger As Open API

Google RPC (GRPC) For Transfer Data Between Microservice

Docker For Run Database Services ( SQL Server , MongoDB ) And Message Broker ( RabbitMQ ) 

پیاده سازی معماری میکروسرویس در دات نت
‫۱ سال و ۷ ماه قبل، یکشنبه ۷ اسفند ۱۴۰۱، ساعت ۱۵:۵۴