Trying to set up caching on our datasets - we're using clr stored procedures -
The database doesn't seem to notify the application of data changes
After much testing, the answer seems to be no... it doesn't seem to work for CLR stored procedures.
Related
I'm have recently started to learn about the micro ORM named Dapper. We usually are relying heavily on stored procedures in MSSQL databases in order to avoid T-SQL together with mixed up with our C# code.
What are your experience with Dapper and stored procedures? Does Dapper require inline T-SQL to fully utilize Dappers all benefits\features?
What are your experience with Dapper and stored procedures?
Dapper is ultimately an object mapper, which works using ADO.Net APIs internally, though it does Cache certain data structures to make queries faster, but it works quite efficiently with the Stored procedures.
Does Dapper require inline T-SQL to fully utilize Dappers all benefits\features?
No, in-fact as Stored procedures are pre-compiled, so unlike Sql text queriues there's no scope of hard parse on every request, since optimum execution plan is already cached in the Sql Server.
In nutshell, stored procedures is indeed an ideal mechanism to use for dapper and SQl server combination for :
Performance
Clean and consistent code
Doing complex database operations, like working with TVP, it can take lot of data in single call and work with it instead of multiple Network request uisng Text queries
AFAIK CoreData can be configured to use sqlite in the persistent store.
so as core-data not provides way to query using SQL.
So core-data has sqlite db in background.
Is it safe to access same db using Core-Data and Sqlite c based api same time?
Will it lead to any data corruption is sqllite or any threading issues.
the reason why am I going to use any wrappers such as FMDB or C based API is to query complex data using sql query
It's probably safe but it's still a really bad idea. Core Data defines its own schema, which is undocumented and which is different from what you would use if you designed a SQL schema. So you'd have to create the Core Data model and then reverse-engineer your own schema to make direct SQL calls.
Also, of course, it's going to be an absolute pain in the ass to keep changes in sync across completely different calling styles.
This is a bad idea, even if it doesn't corrupt your data. You will regret using this approach.
I've done this in the past, before concurrency and subquery expressions existed. I had to make Core Data save everything to disk before using sql. It worked then but you never know if it will work in a future OS X. Nowadays I wouldn't do it. If you need complex queries, use Sqlite only or use Core Data and be creative with predicates and fetch requests.
What's the purpose of stored procedures compared to the use of an ORM (nHibernate, EF, etc) to handle some CRUD operations? To call the stored procedure, we're just passing a few parameters and with an ORM we send the entire SQL query, but is it just a matter of performance and security or are there more advantages?
I'm asking this because I've never used stored procedures (I just write all SQL statements with an ORM and execute them), and a customer told me that I'll have to work with stored procedures in my next project, I'm trying to figure out when to use them.
Stored Procedures are often written in a dialect of SQL (T-SQL for SQL Server, PL-SQL Oracle, and so on). That's because they add extra capabilities to SQL to make it more powerful.
On the other hand, you have a ORM, let say NH that generates SQL.
the SQL statements generated by the ORM doesn't have the same speed or power of writing T-SQL Stored Procedures.
Here is where the dilemma enters: Do I need super fast application tied to a SQL Database vendor, hard to maintain or Do I need to be flexible because I need to target to multiple databases and I prefer cutting development time by writing HQL queries than SQL ones?
Stored Procedure are faster than SQL statements because they are pre-compiled in the Database Engine, with execution plans cached. You can't do that in NH, but you have other alternatives, like using Cache Level 1 or 2.
Also, try to do bulk operations with NH. Stored Procedures works very well in those cases. You need to consider that SP talks to the database in a deeper level.
The choice may not be that obvious because all depends of the scenario you are working on.
The main (and I'm tempted to say "only") reason you should use stored procedures is if you really need the performance.
It might seem tempting to just create "functions" in the database that do complex stuff quickly. But it can quickly spiral out of control.
I've worked with applications that encapsulate so much business logic in SQL, that it becomes virtually impossible to refactor anything. Literally hundreds of stored procedures that are black boxes for devs working with the ORM.
Such applications become brittle, hard to debug and hard to understand. By allowing business logic to live in stored procedures you are allowing SQL developers to make design choices that they shouldn't be making, in a tool that is much harder to work in, log and debug than an ORM. I've seen stored procedures that handle payment processing. Truly core stuff. Stuff that becomes so central to an application that nobody dares to touch it, all because some guy with good SQL skills made a script 5 years to fix something quickly, it was never migrated to the ORM and eventually grew into an unmanageable monster, full of tangled logic nobody understands. Devs end up having to blindly trust whatever it's doing. And what's worse, it's almost always outside test coverage, so you may break everything when you deploy, even if your tests pass with mocked data, but some ancient stored procedure suddenly starts acting up.
Abusing stored procedures is one of the worst forms of technical debt you can accumulate. The database, which is the persistence layer, should not be used for business logic. You should keep that distinction as strict as you can.
Of course, there will be cases where an ORM will have horrible performance or simply won't support a feature you need from SQL. If doing things in raw SQL is truly inevitable, only then should you consider stored procedures.
I've seen Stored Procedure Hell. You don't want that.
There are significant performance advantages to stored procedures in some circumstances. Often the queries generated by Linq and other ORMs can be inefficient, but still good enough for your purposes. Some RBDMS (such as SQL Server) will cache the execution plans for stored procedures, saving on query time. For more complex queries that you use frequently, this savings in performance can be critical.
For most normal CRUD, though, I have found that it is usually better for maintainability just to use the ORM if it is available and if its operations serve your needs. Entity Framework works quite well for me in the .NET world most of the time (in combination with Linq), and I like Propel a lot for PHP.
I stumbled over this pretty old question but I am shocked that the most important benefit of Stored Procedures is not even mentioned.
Security and resource protection
Using SPs you are able to grand execution rights for that SP to a user. The user can execute the SP and only that SP. You do not even have to give the user read or write access to the tables used. The user does not even have to know the tables used.
Using ORM you have to give read or/and write access to the tables used and users. The user can read all data from all the tables you granted the rights and even can combine them in queries, if you want it or not, and also can run queries that creates heavy load on the Database server.
This is especially useful in cases where application development and database development is done by different teams and the database is used by more than one application.
The primary use I find for them is to implement an abstraction layer and encapsulate query logic. In the same way that I write functions in a procedural language.
As le dorfier mentions one of the the primary reasons sprocs (and/or views) should be used is to provide an abstraction layer between a database and its clients (web apps, reports, ETLs etc)
This 'DB API' can make it easier to change/refactor your database without necessarily affecting clients.
See - Why use stored procs - for a more in depth discussion
I mainly stick to linq to sql as an ORM and i think its great, but there is still a place for stored procedures. Mainly i use the when the query i want to run is very complex, with many joins (especially outer joins, which suck in Linq), lots of aggregation in subqueries perhaps, recursive CTE's, and other similar scenarios.
For general crud though, there is no need.
hi all
We do know that CommandType property of a SqlCommand object has 3 options: TableDirect, Text and StoredProcedure or "SP".
Knowing that "SP" has benefits over two other options, my question is do you make lots of SP in your own systems?
Or What solution do you have instead of creating SP?
Thank you
Aside of creating Stored Procedures you can use Object Relational Mapping
Such as:
linq to sql
Nhibernate
Entity Framework
Data Access :SP's vs ORMs
Choose the best way that suits you.
In all production system I used SPs and pure ADO.NET Core to access the data. Systems range from having 100-300 tables and about 500-1000 stored procedures.
Most of the Data Access code is generated using a tool. I've posted the source code and sample application on my blog if you're interested in using/modifying it. The tool can generate over 100,000 lines of code in about 20-25 seconds going against a database with about 750 stored procedures.
Data Access Layer - Code Gen
Of course if you're no familiar with Databases, data modeling/design and stored procedures you're probably better off using Linq to SQL or EF4 (Entity Framework version 4) or similar. If you need brute force performance then ADO.NET core along with Stored procedures is the way to go.
Re: your first question
When you go down the path of stored procedures, the number of stored procedures begins to grow continually for the life of the project. Outside of the basic CRUD operations, each stored procedure tends to be tightly bound to a particular problem and not very re-usable. A rule of thumb is that I can expect 8-12 stored procedures for each data table (excluding reference or code tables, such as the list of states or countries).
The very large number of procs makes naming conventions very important so that you can find anything without constantly visually re-scanning the whole list of 400-500 procs.
Re: your second question
There are a lot of ugly things that happen with sql written inside of strings inside of C# or VB.NET -- it's error prone, ugly, etc.
Linq, nHybernate and many others exist, but the "concept count" (the number of things you need to learn to start being productive), is much higher than learning how to write a good stored procedure executer in C#.
I try to make sure that stored procedures are only created for database functionality - not business logic.
It's Database Functionality when I have some database architecture that's a bit obscure and I want to hide that from callers.
It's Business Logic when it is simply the way in which my application adds or updates or how much validation they do, etc., etc.
In this OLE DB msdn example, (yes, it is dated 1997, but still works :)) I'm wondering what the historic point of OLE DB was if you still apparently wrote SQL to interact with the underlying datasource.
The one thing I'm thinking is if the ICommandText was not executed directly on the database, but instead somehow interpretted by OLE DB then passed off as a vendor specific SQL command/command to manipulate underlying datasource in format it understands. Is that true?
The intent of OLE DB technology is to have a generalized way to connect, work with transactions, and work with datasets. But you still have to write SQL queries. Remember, the intent of the SQL language was to have a generic language for querying data (but, as you've seen, certain parts of the language are platform-dependent). How you connect and how you query are mutually exclusive.
And, yes, the CommandText is executed directly in the database.
Perhaps you want something a level up such as NHibernate, Subsonic, Entity Framework, etc.?
I can vouch for the fact that there is NO translation done by OLE DB.
If you have different databases, you would have to provide different SQL statements based on the vendor. Always fun with dates and Oracle vs. MS databases...