1. Avoid following the ‘Hello World’ examples provided with your ORM tool that turns it into an Object to Object Mapping. Database storage is not the same as objects for a reason. You should still have a relational storage design within a relational storage engine such as SQL Server.
2. Parameterized queries are exactly the same as stored procedures in terms of performance and memory management. Since most ORM tools can use either stored procedures or parameterized queries, be sure you’re coding to these constructs and not hard- coding values into your T-SQL queries.
3.Create, Read, Update, and Delete (CRUD) queries can all be generated from the ORM tool without the need for intervention. But, the Read queries generated are frequently very inefficient. Consider writing a stored procedure for complex Read queries.
4. Since the code generated from the ORM can frequently be ad hoc, ensure that the SQL Server instance has ‘Optimize for Ad Hoc’ enabled. This will store a plan stub in memory the first time a query is passed, rather than storing a full plan. This can help with memorymanagement.
5. Be sure your code is generating a parameter size
equivalent to the data type defined within the table in
the database. Some ORM tools size the parameter to
the size of the value passed. This can lead to serious
performance problems.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home