1.) In finiding the existence of the record: Avoid using the count() instead, just simply write “select a from tb where a=param”

2.) In optimizing the performance, avoid using the “JOIN”,
instead you can use “SELECT * FROM t1 WHERE id IN (SELECT id FROM t2)”

Take image field name as n/varchar(max) named mainpic. Insert image name in a that column. Suppose one of the field value is default.jpg. No need to have image datatype.

Make a folder in Application same directory. And store Image with same name as in database in that folder say D:\\project\images\default.jpg

Now in datalist data fetch coding, in image tag.
if at design :

<asp:Image ID=”imgperson” runat=”server”

imageurl=”images/” />

Take image field name as n/varchar(max) named mainpic. Insert image name in a that column. Suppose one of the field value is default.jpg. No need to have image datatype.

Make a folder in Application same directory. And store Image with same name as in database in that folder say D:\\project\images\default.jpg

Now in datalist data fetch coding, in image tag.
if at design :

<asp:Image ID=”imgperson” runat=”server” imageurl=”images/” />

My question is that is this good programing or how much the code is safe if i used dynamic. if no then how can i achieve such functionality. Also let me know some performance tips. i like ur suggestions,query answer very much. mail me if u can, it s absolute pleasure

1).Using minimal logging
2). Max Batch size
3).Disabling triggers
4).Disabling Constraints
5).Controlling the locking behavior
6).Importing data in native format

Use multiple data files for tempdb and if possible place them in seperate disk drives. This will reduce the bottleneck of tempdb.

The tempdb of SQL Server will be used in many occations, e.g: sorting, use of temp tables and variable tables, worktables, etc.

16. Use Index hint if necessary.

“… I have always found it easier to make a change in a stored procedure than changing compiled code and re-releasing.”

Any change to the number or type of input output parameters will require a change to the stored procedure and the application code.

Incidentally you really should be generating most of the DAL layer in any case and it is purely a matter of whether the code resides inside or outside the database. The actual code required (or generated from metadata) is pretty well identical in either case.

I’m not suggesting there are never situations where it makes sense to use stored procedures but the Performance/Security/Maintainability mantra is a falsehood that many appear to believe purely because it has been repeated so often.

I think also relevant here is the LINQ to SQL debate. Microsoft themselves are endorsing dynamic SQL vs Stored procedure code.

Below taken from Simon Evans Blog

http://blogs.conchango.com/simonevans/archive/2007/11/11/LINQ-to-SQL_3A00_-Let-the-debate-begin.aspx

So with LINQ to SQL (and LINQ to Entities) the most hotly debated point was around the auto generation of LINQ’s dynamic SQL vs. using stored procedures. In the old days, one point favoring of using stored procedures was the performance gain from a cached execution plan. But since SQL Server 2005, dynamic SQL is also cached, so this reason for using stored procedures has largely gone away. One benefit dynamic SQL has over stored procedures is that you only select what you need in all cases. In a typical scenario with stored procedures and a DAL populating an object model, stored procedures will tend to be reused even when all of data is not used by the calling DAL method. There ways around this, but it largely involves an ever increasing list of stored procedures (GetObjectByX), make the solution less manageable.

Even though the paper says that access to docs over 1MB in size performs better when they are stored on the filesystem, this ignores issues of backup and referential integrity that could make it advantageous to keep larger docs in the database.

An important message from the paper is that databases are able to process larger objects than they could do in the past. IMO this trend will continue, and the DB designer needs to know works best with current software and hardware rather than always confining large objects to the filestore.

http://www.beansoftware.com/ASP.NET-Tutorials/Images-Database.aspx

As I’ve been learning SQL over the past 8-9 months with virtually no mentor, I’ve been writing feeble queries using mostly temp tables. What would you recommend as a good resource for us self-teaching types to get away from our feeblness?

People are correct in noting that as far as query performance there is not a performance gain over ad-hoc SQL (particularly parameterized), but there are gains in maintainability and security. I have always worked in small shops where I have done both SQL DBA/Development and application development and I have always found it easier to make a change in a stored procedure than changing compiled code and re-releasing.

I also think that all of these DO refer to performance because the time it takes to develop and maintain the database and application need to be taken into account which is why commenting, naming conventions, and coding standards are important.

IMO #15 Use set-based solutions whenever possible.