نظرسنجی در مورد ارتباط با بانک اطلاعاتی

[Future]

سلام دوستان, من دارم با MVC توی asp.net کار می کنم. این امکان را داررم که query هام رو داخل خود asp بنویسم حتی اگه عمل درج و ویرایش و ... را دارم می تونم توی خود محیط بنویسم. به نظر شما اساتید اگه من تمام کارهای که قراره با بانک ارتباطی انجام بشه را بصورت SP داخل اس کیو ال بنویسم و بعد در asp اونا را صدا کنم و پارامتر پاس کنم بهتر هست یا اینکه اونا مستقیما داخل Asp بنویسم. آیا روش بهتری هم عیر از این دو روش هست؟
ممنون میشم اگه یه روش صحیح و کارآمد و مفید را بیان کنید.

با تشکر

[maxpayn2]

sp بهتره ، فرض کن اشتباها در یک select به جای اینکه صعودی سورت کرده باشی نزولی سورت کنی ، بعد از پابلیش و آپلود پروژه متوجه این اشتباه میشی ، باید سورس رو تغییر بدی ، دوباره پابلیش کنی و دوباره آپلود کنی که خیلی بده ، حالا فکر کن این اشتباه روی یک select در چند صفحه اتفاق افتاده باشه ، باید سورس تمام صفحات رو تغییر بدی ، ولی اگه sp داشته باشی ، به SQL Server وصل میشی و اون رو تصحیح میکنی

[naser2009]

سلام دوستان
با تایید حرفای دوستان
نگاه کن دوسته من باید این رو مدنظر داشت که هر کاری رو باید سپرد دست نرم افزار مورد نظر خودش
در واقع اگه توجه داشته باشی:
Sql server واسه این کار(اجرای query ها) و مسائل database بهینه شده
Visual studio واسه مسائل برنامه نویسی کامپایل و optimazation کدها و غیره
ولی واسه مسائل مربوط به parsing کوئری ها باید 100% یه سری کارهای اضافه رو انجام بده

لذا من نظرم استفاده صرف از stored procedure در هنگام ارتباط با بانک اطلاعاتی است.
در ضمن امنیت رو هم بیشتر میکنه مخصوصا در حالتی که query ما دارای پارامتر می باشد و از مسائلی همچون sql injection جلوگیری می کند.

در ضمن یه مساله دیگه این که شما که داری با چنین platform ای (mvc) کار میکنی واقعا حیفه که بخواهی queryها رو داخل کد برنامه بنویسی و امنیت که یکی از مولفه های بارز mvc است رو زیر سوال ببری

در ضمن الان با پیشرفت کدها و سیستم های توسعه سریع(RAD)-(Rapid application development) شما دیگه لازم نیست کدهای تکراری واسه ارتباط با بانک بنویسی و یا stored procedure ها رو از اول تا آخر بنویسی

از جمله این برنامه ها ، برنامه stored procedure generator آقای کرامتی مدیر کل سایته که چند وقت پیش امکان اینکه لایه های کلاس dal رو بگیریم برایمون فراهم کرد یا برنامه هایی دیگه مثله n-hibernate و غیره که واقعا سرعت توسعه نرم افزار رو بالا می برند
با تشکر

[Alireza_Salehi]

قطعا SP کیفیت و سرعت بالاتری به شما ارائه می کند.

ولی SP نوشتن کار بیشتر ی می طلبد، شما می توانید با استفاده از LINQ و EF سرعت نوشتن برنامه را بالا ببرید و سرعت و کیفیت نسبتا مناسبی را هم تجربه کنید.

در پروژه های کوچک و متوسط همان LINQ و EF کار راه بنداز هستند. ولی در پروژه های بزرگ با کوئری های سنگین SP بهتر است.

نظر دوستمون در مورد پابلیش کردن رو هم قبول ندارم، به هزار دلیل دیگه که دیتابیس در اونها شرکت نداره ممکنه لازم بشه سایت مجدد پابلیش بشه.... ساده شند پابلیش دلیل مناسبی نیست.

[Mostafa_Dindar]

در واقع وقتی از Stored Procedure استفاده میکنیم , اولین بار که که به اون sp درخواست داده میشه , SQL Server اون رو Compile میکنه و واسش Execution Plan رو میسازه که اونها رو Cache میکنه تا دفعات بعدی لازم نباشه اعمال Parse ,Compile و Execution Plan رو واسه اونها تکرار کنه .

پس از لحاظ تکنیکی سریعتر از کوئری های Ad Hoc هستند . از سوی دیگر استفاده از Stored Procedure به طور قابل توجهی مقدار Sql Injection رو نسبت به کوئری های Ad Hoc کم میکنند .

با اینکه کوئری های LINQ از نوع Ad Hoc هستند ولی به طور قابل ملاحظه ای بهینه هستند , حتی در موارد بسیاری از SP های برنامه نویسان کم تجربه خیلی بهتر عمل میکند .

درست است که نوشتن sp احتمال SQL Injection رو کاهش داد ولی میتونید SP های زیادی بنویسید که راه رو برای SQL Injection ها باز بزارند . ولی LINQ به طور قابل توجهی جلوی SQL Injection ها رو میگیره , و تفاوتی ندارد که شما چقدر در LINQ مسلط باشید , در هر صورت LINQ مساله SQL Injection رو تا حد خیلی زیادی هندل خواهد کرد .

استفاده از LINQ To SQL در پروژه های کوچک و متوسط پیشنهاد شده .پس اگر میخواهید پروژه Enterprise ای داشته باشید که سرعت و Performance اون خیلی مهم هست , باید دست به کار شوید و SP ها رو بدین یک متخصص SQL یا پایگاه داده بنویسه .

معمولا Code Generator های که SP تولید میکنند , اعمال خیلی ساده CRUD رو انجام میدند , و هر کدام رو به چند صورت انجام میدن . مثلا Delete By Index , Delete By Primary key , Delete By Foreign Keys و ....

ولی نیازهای یک پروژه بزرگ تنها با اون SP ها برطرف نمیشه , و باید Query های واقعا پیچیده و بهینه ای رو بنویسید .

سربلند باشید

[maxpayn2]

نظر دوستمون در مورد پابلیش کردن رو هم قبول ندارم، به هزار دلیل دیگه که دیتابیس در اونها شرکت نداره ممکنه لازم بشه سایت مجدد پابلیش بشه....

پس چون به دلایل زیادی از قبیل سوختگی ، خفگی ، برق گرفتگی و ... ممکنه آدم بمیره میشه مثلا برای برق گرفتگی هیچ پیشبینی نکرد ، چون به دلایل دیگه ای هم ممکنه آدم بیمره ، برنامه نویس خوب کسیه که تا جایی که ممکنه جوری کد بنویسه که حداقل احتیاج به پابلیش مجدد باشه



در واقع وقتی از Stored Procedure استفاده میکنیم , اولین بار که که به اون sp درخواست داده میشه , SQL Server اون رو Compile میکنه و واسش Execution Plan رو میسازه که اونها رو Cache میکنه تا دفعات بعدی لازم نباشه اعمال Parse ,Compile و Execution Plan رو واسه اونها تکرار کنه .

دقیقا همین سوال از جناب آقای کرامتی (DelphiAssistant (http://barnamenevis.org/forum/member.php?u=1206)) پرسیده شد و ایشون به شدت این مساله رو تکذیب کرده و فرمودن کسانی که در سایت هاشون همچین ادعایی میکنن ... هستن




درست است که نوشتن sp احتمال SQL Injection رو کاهش داد ولی میتونید SP های زیادی بنویسید که راه رو برای SQL Injection ها باز بزارند . ولی LINQ به طور قابل توجهی جلوی SQL Injection ها رو میگیره , و تفاوتی ندارد که شما چقدر در LINQ مسلط باشید , در هر صورت LINQ مساله SQL Injection رو تا حد خیلی زیادی هندل خواهد کرد .

وقتی میشه با یه کم دقت در کد نویسی جلوی SQLInjection رو گرفت چرا performance رو فدای بی دقتی کنیم ؟

[Alireza_Salehi]

پس چون به دلایل زیادی از قبیل سوختگی ، خفگی ، برق گرفتگی و ... ممکنه آدم بمیره میشه مثلا برای برق گرفتگی هیچ پیشبینی نکرد ، چون به دلایل دیگه ای هم ممکنه آدم بیمره ، برنامه نویس خوب کسیه که تا جایی که ممکنه جوری کد بنویسه که حداقل احتیاج به پابلیش مجدد باشه
دقیقا همین سوال از جناب آقای کرامتی (DelphiAssistant (http://barnamenevis.org/forum/member.php?u=1206)) پرسیده شد و ایشون به شدت این مساله رو تکذیب کرده و فرمودن کسانی که در سایت هاشون همچین ادعایی میکنن ... هستن
وقتی میشه با یه کم دقت در کد نویسی جلوی SQLInjection رو گرفت چرا performance رو فدای بی دقتی کنیم ؟
نوشتن SP زمان بیشتری می طلبد ضمن این که شخصی که داره SP مینوسیه باید از سواد متوسطی برخوردار باشه (که معمولا این جوری نیست) بنابراین در خیلی موارد صرفه اقتصادی و زمانی استفاده از LINQ به جای SP بیشتره.

در مورد این موضوع کامپایل شدن:
دستورات SQL ی که درون دیتابیس ذخیره می شوند قطعا سربار کمتری نسبت به دستوراتی دارند که از خارج دیتابیس و توسط برنامه فراخوانی می شوند.
ویکیپدیا: (http://en.wikipedia.org/wiki/Stored_procedure)

Overhead: Because stored procedure statements are stored directly in the database, this may remove all or part of the compilation overhead that is typically required in situations where software applications send inline (dynamic) SQL queries to a database. (However, most database systems implement "statement caches" and other mechanisms to avoid repetitive compilation of dynamic SQL statements.) In addition, pre-compiled SQL statements, while avoiding some overhead, add to the complexity of creating an optimal execution plan because not all arguments of the SQL statement are supplied at compile time. Depending on the specific database implementation and configuration, mixed performance results will be seen from stored procedures versus generic queries or user defined functions.SQLPerformance.com (http://www.sql-server-performance.com/articles/per/optimizing_sp_recompiles_p1.aspx)

When a stored procedure recompiles, it places a compile lock on the objects referenced by the stored procedure, and if there are enough stored procedure recompiles, the database may experience blocking. While all databases will experience stored procedure recompiles as a normal matter of database operations, it is when a stored procedure recompiles with every run that a database administrator or Transact-SQL developer needs to look out for and determine a remedy.

MSDN (http://msdn.microsoft.com/en-us/library/aa174792%28SQL.80%29.aspx)

In SQL Server version 6.5 and earlier, stored procedures were a way to partially precompile an execution plan. At the time the stored procedure was created, a partially compiled execution plan was stored in a system table. Executing a stored procedure was more efficient than executing an SQL statement because SQL Server did not have to compile an execution plan completely, it only had to finish optimizing the stored plan for the procedure. Also, the fully compiled execution plan for the stored procedure was retained in the SQL Server procedure cache, meaning that subsequent executions of the stored procedure could use the precompiled execution plan.
SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans. The database engine uses an efficient algorithm for comparing new Transact-SQL statements with the Transact-SQL statements of existing execution plans. If the database engine determines that a new Transact-SQL statement matches the Transact-SQL statement of an existing execution plan, it reuses the plan. This reduces the relative performance benefit of precompiling stored procedures by extending execution plan reuse to all SQL statements.
حتما مایکروسافت که خودش تولید کننده محصول بوده نمیدونه توش چه خبره. شما بهتر میدونی!

روی وب انواع و اقسام متد ها و روش های کاش precompile یا recompile برای sp ها هستش اونوقت شما کل قضیه رو میبری زیر سوال؟



SP نوشتن خیلی بهتر از اینه که توی csharp یک کوئری بنویسید و اجرا کنید ولی همیشه به اون قدر سرعت SP نیازی نیست. سرعت نوشتن برنامه مهمتره که LINQ اونجا به کار میاد.

[maxpayn2]

نوشتن SP زمان بیشتری می طلبد ضمن این که شخصی که داره SP مینوسیه باید از سواد متوسطی برخوردار باشه (که معمولا این جوری نیست) بنابراین در خیلی موارد صرفه اقتصادی و زمانی استفاده از LINQ به جای SP بیشتره.

به نظر من کسی که حتی سواد متوسط هم نداره در صورت پذیرفتن پروژه ، خائن محسوب میشه . در ضمن صرفه اقتصادی و زمانی قبوله و تعهد کاری مهمتره


در مورد این موضوع کامپایل شدن:
دستورات SQL ی که درون دیتابیس ذخیره می شوند قطعا سربار کمتری نسبت به دستوراتی دارند که از خارج دیتابیس و توسط برنامه فراخوانی می شوند.

حتما مایکروسافت که خودش تولید کننده محصول بوده نمیدونه توش چه خبره. شما بهتر میدونی!

روی وب انواع و اقسام متد ها و روش های کاش precompile یا recompile برای sp ها هستش اونوقت شما کل قضیه رو میبری زیر سوال؟

من نبردم زیر سوال جواب سوال پرسیده شده رو گفتم ، ممنون که راهنمایی کردین ، باید به آقای کرامتی نشون بدم نظرشون رو بپرسم

[اوبالیت به بو]

سلام

جنابAlireza_Salehi (http://barnamenevis.org/forum/member.php?u=33355)
Linq با 3 لایه نویسی مشکل نداره؟

[Alireza_Salehi]

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

توی اکثر شرکت ها برنامه نویس هایی که SP مینویسن خیلی از نکات ساده و ابتدائی رو رعایت نمی کنند، من موارد بسیاری دیده ام، از شرکت هایی که پروژه های چند میلیاردی میگیرند تا شرکت هایی که پروژه های چند میلیونی می گیرند.

برای چنین آدمهایی همون LINQ یا DataSet یا ابزارهای مشابه بهتر جواب میده.


من چند بار هم عرض کردم خودم اگر قرار باشه انتخاب کنم در یک پروژه بزرگ قطعا SP گزینه اول و آخر است، هر چند استفاده از LINQ در کوئری هایی که در چند لحظه جواب می دهند اشکالی ندارند.



واقعیت بازار کار نرم افزار چیز دیگری است برادر، تعهد یعنی ایکه با توجه به دستمزدی که به شما می دهند شما بهترین کار را ارائه دهید و کم فروشی نکنید. وقتی مشتری دستمزد استفاده از LINQ (درگ کردن جداول و چند خط کد نویسی) را می دهد نمی تواند انتظار استفاده از SP را داشته باشد. وقتی برای مشتری توضیح میدهی و قبول نمیکند، تقصیر خودشه، یک روزی میرسه که LINQ جواب کارش رو نمیده و باید برای بهینه سازی برنامه و تبدیل لایه DAL از LINQ به SP مجدد خرج کند.

[Alireza_Salehi]

سلام

جنابAlireza_Salehi (http://barnamenevis.org/forum/member.php?u=33355)
Linq با 3 لایه نویسی مشکل نداره؟
معماری سه لایه، معمولا شامل سه لایه زیر است:
Business
Data Access
Presentation

با توجه به امکانات موجود در VisualStudio و بستر دات نت برای لایه DataAccess چهار روش زیر را در اختیار دارید:
1. DataSet
DBML (LINQ To SQL Classes) .2
Entity Framework .3
4. کلاسهایی که خودتان مبتنی بر ADO.NET طراحی می کنید (با استفاده از Connection, Command, DataReader,DataAdapter).

اینها همه ORM های مایکروسافت هستند(نگاشت پایگاه داده رابطه ای به اشیاء) .هر کدام از 4 مورد فوق مزایا و معایب خاص خود را دارند که قابل بحث است.

برای اطلاعات بیشت در مورد قابلیت های EF به عنوان لایه Data Access به این لینک:
http://blogs.objectsharp.com/cs/blogs/barry/archive/2008/04/27/the-entity-framework-vs-the-data-access-layer-part-0-introduction.aspx

و برای آشنائی با 20 مدل مختلف از ORM های غیر مایکروسافتی به این لینک مراجعه کنید:
http://howtoselectguides.com/dotnet/ormapping/#section-vendors

[maxpayn2]

اون دنیایی که همه وقتی کاربلد هستن پروژه میگیرن من تاحالا جائی ندیدم.

توی اکثر شرکت ها برنامه نویس هایی که SP مینویسن خیلی از نکات ساده و ابتدائی رو رعایت نمی کنند، من موارد بسیاری دیده ام، از شرکت هایی که پروژه های چند میلیاردی میگیرند تا شرکت هایی که پروژه های چند میلیونی می گیرند.

برای چنین آدمهایی همون LINQ یا DataSet یا ابزارهای مشابه بهتر جواب میده.


من چند بار هم عرض کردم خودم اگر قرار باشه انتخاب کنم در یک پروژه بزرگ قطعا SP گزینه اول و آخر است، هر چند استفاده از LINQ در کوئری هایی که در چند لحظه جواب می دهند اشکالی ندارند.



واقعیت بازار کار نرم افزار چیز دیگری است برادر، تعهد یعنی ایکه با توجه به دستمزدی که به شما می دهند شما بهترین کار را ارائه دهید و کم فروشی نکنید. وقتی مشتری دستمزد استفاده از LINQ (درگ کردن جداول و چند خط کد نویسی) را می دهد نمی تواند انتظار استفاده از SP را داشته باشد. وقتی برای مشتری توضیح میدهی و قبول نمیکند، تقصیر خودشه، یک روزی میرسه که LINQ جواب کارش رو نمیده و باید برای بهینه سازی برنامه و تبدیل لایه DAL از LINQ به SP مجدد خرج کند.

نظر شخصیم رو گفتم ، وگر نه با شما کاملا موافقم

[Mostafa_Dindar]

مایکروسافت در سایت رسمیش این 4 تا رو به عنوان ORM های Open Source معرفی ( یا پیشنهاد ) کرده :
NHibernate (https://www.hibernate.org/343.html)

NHibernate is a port of Hibernate Core to the .NET Framework. It handles persisting plain objects to and from an underlying relational database. Given an XML description, NHibernate automatically generates SQL to load & store the objects.


Fluent NHibernate (http://fluentnhibernate.org/)

Fluent, XML-less, compile safe, automated, convention-based mappings for NHibernate.



Castle ActiveRecord (http://www.castleproject.org/activerecord/)

The Castle ActiveRecord project is an implementation of the ActiveRecord pattern for .NET. The ActiveRecord pattern consists of instance properties representing a database record, instance methods acting on that specific record, & static methods acting on all records.

SubSonic (http://www.subsonicproject.com/)

SubSonic is A Super High-fidelity Batman Utility Belt that works up your Data Access (using Linq in 3.0), throws in some much-needed utility functions, and generally speeds along your dev cycle.

[Future]

سلام
میشه بگید entity frame work چی هست؟ از کجا باید دانلودش کرد. ممنون میشم اگه یکم بیشتر در باره entity frame work بدید. آخه من وقتی روی پروژه راست کلیک می کنم و Add رو انتخاب می کنم فقظ گزینه های Linq to Sql وDataset رو میبینم. حالا از کجا باید این گزینه رو add کرد

[Alireza_Salehi]

سلام
میشه بگید entity frame work چی هست؟ از کجا باید دانلودش کرد. ممنون میشم اگه یکم بیشتر در باره entity frame work بدید. آخه من وقتی روی پروژه راست کلیک می کنم و Add رو انتخاب می کنم فقظ گزینه های Linq to Sql وDataset رو میبینم. حالا از کجا باید این گزینه رو add کرد
ویکیپدیا:
http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

باید یکی از موارد زیر را داشته باشید:

1. Visual Studio 2008 SP1
از منوی Add New Item گزینه ADO.NET Entity Data Model را انتخاب نمائید. فایلی با پسوند edmx به پروژه شما اضافه می کند.

2. Visual Studio 2010
در این حالت سه گزینه در اختیار دارید که اولی مشابه 2008 است.
ADO.NET Entity Data Model
ADO.NET Entity Object Generator
ADO.NET Self-Tracking Entity Generator


در اینجا هم یک مثال از نحوه استفاده وجود دارد:
http://www.aspfree.com/c/a/ASP.NET/Introduction-to-the-ADONET-Entity-Framework-using-ASPNET/

[maktab]

من مطالب رو خوندم و چون برام امنیت خیلی مهمتر از زمان صرف شده برای برنامه نویسی است sp رو انتخاب می کنم. چندتا سوال برام پیش آمده:
- چرا اصلا sp امنیت بیشتری نصبت به EF داره؟ و این EF ساختار داخلیش کجاست؟ (خب حتما برای ارسال و دریافت اطلاعات از دستورات sql استفاده می کنه ولی این دستورات کجا هستن؟)
- حالا وقتی از sp استفاده میکنم برای ذخیره سازی اطلاعات در خود سایت (برای دسترسی) از چه روشی بهتره استفاده کنم؟ از دیتاست، لیست های ژنریک + کلاس های کنترلی (چیزی شبیه به خود EF ولی خودم کد نویسی کنم) و...