I was trying to migrate from Another RDBMS to cockroachDB but I think there is no such functionality like stored procedures in Cockroach. So what is the best alternative to make a stored procedure in cockroachDB ?
CockroachDB does not support stored procedures and the best alternative would depend on the problem you are trying to solve. A few examples:
If the stored procedure contains business logic, we'd recommend moving that logic to the application.
Simple stored procedures that contain a single DML statement should be moved into the application's DataAccess logic.
More complex stored procedures that contain explicit transactions or error code should be moved to the application-level transactions.
EDIT: Stored Procedures as a Litmus Test, an article by Joe Emison, compares Stored Procedures to other solutions. It may be helpful in understanding alternatives.
CockroachDB is distributed SQL and natively suits serverless patterns. As a stored proc is just a way to ensure procedural consistency, you could probably get by using serverless functions (whatever flavor). The idea is the serverless function is a proxy for the stored procedure.
While it is possible for a procs to call other procs, common advice is to avoid having serverless functions call each other. It would be reasonable to develop a cloud library (JavaScript, for example) which models all the DB constraints. Then each serverless function becomes an endpoint (proc) and the library provides the means to reuse/shared logic.
Related
I'm in the planning stages of a Microsoft ASP.NET / SQL Server 2008 based web application and In thinking about database design, I began to think about injection attacks and what strategies I should employ to mitigate the database as a vector for injection attacks.
I've heard from various sources that using stored procedures increases safety, I have also read that these are equally as infective if they are still used with dynamic SQL as this presents an injection point
Question
Is it possible to use a Parametrized Query inside a stored procedure? My thinking is that if I pass the arguments to the stored procedure into the prepared statement the database engine will sanitize those arguments for me.
Yes you can pass Parametrized query inside a store procedure.
but it think it will not use execution plan in the procedure
and work slow as per my knowledge.
Can anyone say Stored procedures pros and cons AND Java Stored Procedures pros and con? And how to test it.
Best regards!
The arguments for and against stored procedures tend to split on what you think is the correct answer to the question: does business logic belong in the database or the application? I will try to be neutral in my presentation of the arguments. If I succeed some of my pros and cons will contradict themselves.
PRO
Stored procedures make it easy to share database code across applications
Co-locating data-related logic with the data makes it easy to enforce business rules across applications. This approach privileges the data owner over the data user.
Stored procedures use a language tailored to database programming.
Stored procedures scale with the database.
CON
Business logic does not belong in the database.
Stored procedures are written in specialist and clunky programming languages which the average developer has no interest in learning.
We can't ask the DBA to write stored procedures because DBAs hate developers.
Stored procedures run in the database and the database is the bottleneck.
Many of these general points also apply to Java Stored Procedures. I wrote an answer to your related question, so these Pros and Cons may seem familar.
PRO
Java stored procedures allow us to extend the functionality accessible to database programs.
In particular it can allow us greater flexibility to integrate operations in the database and the OS domains.
Lots of developers know how to write Java.
Java stored procedures allow us to deploy our database application across different DBMS products.
CON
Java does not perform as well as native database code.
Java stored procedures entail writing bespoke code which duplicates built-in functionality..
Java is not tailored to database operations.
Java can pose security problems. especially when it comes to running programs on the OS from inside the database.
The following is true of native stored procedures and Java stored procedures: code written by developers with no understanding of how databases work can perform really badly. This applies equally to front-ends built or ORM tools configured without the appropriate level of expertise. However, this situation is less likely to arise with native stored procedures because their functionality is shaped towards building efficient database applications.
Stored procedures pro:
-Secure
-Performance and scalability
-Allows for changes to one tier (the database itself rather then the actual code of the
interface / web page)
-Can be scripted out or moved over easily
I am looking to insert and update records in a database using functions and logic that are not available in SQL Server or any other RDBMS for that matter. After Googling around a bit this morning, I have come across the concept of Extended Stored Procedures. As far as I can tell, I should be able to compile my desired functionality into a dll, make a stored proc utilizing that dll to do the inserting/updating.
However, most of the articles and examples I have come across are somewhat dated (~2000). Are extended stored procedures still an acceptable practice? I am far from an expert in this area, so any other suggestions or comments would be greatly appreciated.
If you're using SQL Server 2005 or later, SQL CLR is the area to look at. You can call .NET code from within SQL Server.
This article on MSDN is a good place to start.
Are extended stored procedures still
an acceptable practice?
No, they are officialy deprecated and will be dicontinued in a future release. See Deprecated Database Engine Features in SQL Server 2008 , in the Features Not Supported in a Future Version of SQL Server table:
Extended stored procedure programming: Use CLR Integration instead.
I usually recommend against using CLR procedures, in most cases you can refactor the problem you are facing, into something that Transact Sql can handle.
Of most concern is the procedural approach that often accompanies the use of CLR procedures, when a relation database performs best when performing set based operations.
So the first question I always ask, is there anyway to refactor the problem into a set based operation.
If not, then I ask why would you want to execute the code inside of the database server, instead of in an application layer? Think about the performance impact you might have by placing the logic inside the database. (This might not be an issue if your db server has plenty of extra processing time).
If you do go head with CLR procedures, I think they are best applied to intensive calculations and complex logic.
Linq to SQL and Linq to Entities depend on creating dynamic SQL to do a lot of their work, specially when you have classes represent database tables in some fashion. However if the database(s) does not allow ad hoc SQL queries and everything has to go through stored procedures, I don't see the big value of using L2Q or L2E if the developer has to write all the SP's upfront to do all the work AND know that these are the all SPs that will ever be used in all scenarios in the app.
Views might alleviate the situation but if creating views need DBA permissions, it is still a hassle.
LINQ-to-SQL's stored procedure implementations will still return your entity objects; you don't get the super-incredible filtering capabilities that L2S provides by creating dynamic SQL, but you still can use the extensions to parse through.
Like I said, you can still add your schema and when your stored procs return those entities, you get that object relationship mapped already.
I still think it's handy :)
If you are restricted to stored procedures than your best choice is Linq-to-Sql it works fairly well if your goal is to map classes one to one with result sets from stored procedures.
There are some quirks with the designer for sure but once you get them figured out it works very well for mapping result sets to classes.
There is a big difference between using "stored procedures" for ORM and using a tool like NHibernate and mapping straight to your tables.
Mapping straight to tables gives your all the awesome stuff like lazy loading and the repository pattern.
here is my blog post on setting up linq-to-sql using stored procedures, hope it helps
If I were your dba I too would not allow access through any type of dynamic SQL. It is a bad practice to allow direct permissions to the tables, it makes it far too easy for employees to commit fraud or to steal sensistive data. LINQ2SQl also seems to write inefficent code (at least all the examples of the code it writes that I have seen are code I wouldn't allow in my database) and it is much much easier to performance tune stored procedures.
Be grateful you have a good dba who actually cares about database security and performance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there any alternative to stored procedures, secure and fast as well as stored procs. i know only Hibernate. Is there any other technologies like that?
Stored procedures are a place to put code (SQL) which executes on the database, so I understand the question to mean
"is there any other way to package up the code which runs on the database?"
There are several answers:
There is nothing else that is quite the same as a stored procedure, but there are alternatives which you might consider.
You could write all your SQL as strings inside your client code (java or whatever)
This has various problems (loss of encapsulation, tight coupling -> harder maintenance), however, and is not a good idea.
You could use an ORM such as NHibernate, which inserts a layer between your client logic and the database. The ORM generates SQL to execute on the database. With an ORM, it is harder to express complex business logic than in a stored procedure (sweeping generalisation!).
A kind of halfway house is to define your own data access layer (DAL) in java (or watever you're using) and keep it separate from the main body of client code (separate classes / namespaces / etc.), so that your client makes calls to the DAL, and the DAL interprets these and sends SQL to the database, returning the results from the database back to the client.
Yes. you can use dynamic sql, but I personally like stored procedures better.
1) If you're using MS SQL Server, it will generate a query plan which should enable the stored procedure to execute faster than simple dynamic sql.
2) It can be easier an more effective to fix a bug in a stored procedure, expecially if your application calls that procedure in several spots.
3) I find it's nice to encapsulate database logic in the database rather than in embedded sql or application config file.
4) Creating stored procedure into the database will allow sql server to do some syntax, and validation checks at design time.
Hibernate is an object/relational persistence service.
Stored procedure is a subroutine inside a relational database system.
Not the same thing.
If you want alternative to Hibernate, you can check for iBatis for Spring
You can do dynamic SQL as secure and fast as stored procedures can be, it just takes some work. Of course, it takes some work to make stored procedures secure and fast also.
A stored procedure is a subroutine
available to applications accessing a
relational database system. Stored
procedures (sometimes called a proc,
sproc, StoPro, or SP) are actually
stored in the database data
dictionary.
Typical uses for stored procedures
include data validation (integrated
into the database) or access control
mechanisms. Furthermore, stored
procedures are used to consolidate and
centralize logic that was originally
implemented in applications. Large or
complex processing that might require
the execution of several SQL
statements is moved into stored
procedures, and all applications call
the procedures only.
Stored procedures are similar to
user-defined functions (UDFs). The
major difference is that UDFs can be
used like any other expression within
SQL statements, whereas stored
procedures must be invoked using the
CALL statement
..from Wikipedia
I think you need to read this article and reframe your question. Hibernate has nothing to do with stored procs.
Hmm, seems to me that the obvious alternative to stored procedures is to write application code. Instead of, say, writing a store procedure to post a debit every time a credit is posted, you could write application code that writes both.
Maybe I'm being too simplistic here or missing the point of the question.
It'd help a little more if you said why you are looking for alternatives,
what about stored procs do you not like?
Some databases (eg. PostgreSQL) also allow you to write stored procedures in
different languages. So if you really want to you can write them in Python or
Java or the like, instead of SQL.
I think the OP means that an alternative to writing all his database code directly in his application code is either to call stored procedures or to introduce a layer of separation between his application code and database using an ORM such as Hibernate, but yes they are very different things.
Using stored procedures let you keep your SQL in one place separate from your application code. Using Hibernate allows you to avoid writing SQL completely and provides an object representation of the relational database.
Which way you go depends alot on the application and your own preferences.