Is there support for stored procedures in Google Bigtable, or support for any similar mechanism for saving multi-statement queries?
Related
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.
We have Stage database, which contains stored procedures, and transfers data into an OLTP Database.
Do Elastic SQL Databases reside on same server, and give ability to conduct cross-db stored procedure transactions?
Would Elastic databasepool allow this?
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-elastic-pool
You can achieve elastic transactions spanning across databases using .NET client applications. This is currently under preview.
Elastic transactions at server side are planned in future.
for more information
Why hive is not supporting Stored procedure?
If its not supporting then how we will handle Sp in Hive? have any alternate solution?
(Because we have a already a data base is there in mssql)
What about HBASE? Is it support SP?
First of all, Hadoop or Hive is NOT an alternative to your SQL DB. You must never consider either of these 2 to be used as a replacement of your RDBMS.
Hive was developed just to provide warehousing capabilities on top of an existing Hadoop cluster keeping in mind the large base of SQL users, both expert database designers and administrators, as well as casual users who use SQL to extract information from their data warehouses. Although it provides you a SQL like interface, it is not a SQL DB. Hive is most suited for data warehouse applications, where relatively static data is analyzed, fast response times are not required, and when the data is not changing rapidly. Simply put for offline batch processing kind of stuff.
There is nothing like stored procedures in HBase as well. But they have something called as Coprocessor which resembles stored procedures in RDBMS. To find more on Coprocessor you can go here.
And as #zsxwing has said Sqoop is just a data migration tool, nothing more. Once you switch to the NoSQL world you need to be flexible and you need to abide by the NoSQL rules.
If you could elaborate your use case a bit, maybe we can help you better.
In response to your comment :
Yes Facebook uses Hadoop and Hive and other related tool extensively. Infact Hive was developed at Facebook. But These are not the only things. Wherever they have OLTP and full transactional need, they still depend on RDBMS. One example is their Timeline feature, which uses MySQL. They have a gigantic(and awesome) pipeline which consists of a lot of things and not just Hadoop and Hive. See the picture below.
Hive and Hbase are not support stored procedure. However, Hive plans to support Sp (HIVE-3087) in the future. HBase has no plan about supporting Sp since it only focuses on being a Storage and more like NoSQL.
Hive UDF could implement some function of stored procedure, though it's not enough.
Hive does not have stored procedures
Hive indeed does not have any stored procedures as explained in existing answers. However, here are 2 mitigating factors:
Hive has views
Of course it is not a proper substitute for stored procedures, but with smart use of views you can perhaps remove the need for some of your procedures.
You can call hive from another program
The last time I ran into the problem that hive does not have stored procedures, I realized that the thing I wanted to do (loop over all columns) was something that I could also do in another program. As such I followed the following workflow:
Run a query to get the relevant (meta) data: Python calls hive to get column names
Use the information to build the query: Python takes in all column names and builds the correspondng select statements
Run the resulting query: Python does a system call with hive -e
Optionally, go to 2 if needed
With views and external calls, I have so far been able to work around the lack of stored procedures.
Please refer to HPL/SQL, I am looking for same solution but not try yet.
I believe the data warehouse application need stored procedure support, but prefer set-based than row-based procedure.
In my personal experience, procedural support is needed when leverage server-side program template in structured data warehouse application. It makes data warehouse application more easy to porting between SQL/NoSQL, like Netezza, MSSQL, Oracle, DB2, and BigInsight.
Have a look at open-source project PL/HQL at http://www.plhql.org. It allows you to run existing SQL Server, Oracle, Teradata, MySQL etc. stored procedures in Hive.
Because I have several unrelated resources to coordinate during commit, I would like to use two-phase commit (2PC) on Azure SQL Database, from Java code (JDBC).
On standard SQL Server, you can do a complex install of some DLL plus some scripts to make available some extended stored procedures, with names like xp_sqljdbc_xa_init or xp_sqljdbc_xa_prepare, that in turn the Microsoft JDBC driver uses to provide the XA semantics of start/end/prepare/commit. But these extended stored procedures aren't available on Azure from what I can see.
Also, by itself, SQL Server doesn't seem to have any PREPARE TRANSACTION primitive, and I don't find one in Azure either.
So how can one do 2PC on Azure?
It's not supported and in many ways incompatible with the benefits and uses cases for cloud computing. There's an excellent blog post by Clemens Vasters that I'd recommend reading and which introduces the service bus feature as a way to accommodate the key aspects of the behavior that you may be looking for.
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