When writing Snowflake procedures is there any benefit of writing procedures in JavaScript or SQL or vice versa.
It depends upon the environment in the organization, if team has experience in JavaScript then they would write in JavaScript.
Is there any recommendation by Snowflake on what to use when ?
Usually you will get the best performance with a pure SQL solution, but not always:
A UDTF in JS/Java/Python can be faster as it can use less resources (manage memory requirements): https://towardsdatascience.com/sql-puzzle-optimization-the-udtf-approach-for-a-decay-function-4b4b3cdc8596
Sometimes some complicated SQL UDFs don't work inside a larger query, then JS/Java/Python can solve the problem: https://stackoverflow.com/a/65299548/132438
Java has a nice packaging mechanism to move from a software engineer's environment to Snowflake: Use a .jar.
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.
This seems to be a duplicate of the other question with the same title, but it actually isn't.
We have our business logic implemented mostly as DB2 stored procedures (I see that H2 has a DB2-compatibility mode - nice!).
How can we use H2 for in-memory unit testing with these procedures?
Unfortunately H2 seems to lack the CREATE PROCEDURE command from its grammar.
I don't want to use Java functions as stored procedures. It would be best if the very same sql files could be used for testing and production as well... am I asking too much?
EDIT: we also use SQL cursors... again, no sign of support :-(
Unfortunately, the compatibility mode doesn't go as far as supporting SQL prodecures. Currently, the only solution is to use Java functions. SQL cursors are also not supported, sorry. But I will add these feature requests to the roadmap. Patches are welcome of course :-)
I don't know between ADO, DAO and DLookUps and such. Does anyone know?
I find that the application bottleneck is usually the actual SELECT/INSERT/UPDATE on the DB and not how the application calls it. if you are worrying about speed make sure you have well designed tables and indexes.
Regarding DAO vs ADO, I'm not sure about a difference in performance but there is a difference in available functionality.
There is a microsoft article showing the differences in a nice table. Choosing ADO or DAO.
It also states:
"In particular, ADO is a good choice if you are developing an Access database solution that will later be upgraded to SQL Server — you can write your ADO code to minimize the number of changes that will be required to work against a SQL Server database. In addition, ADO is a good choice for developing new data access components that work with SQL Server, multidimensional data, and Web applications."
Seems like ADO might be the way to go.
I don't know anything about DLookUps though.
I am developing a data driven website and quite a lot of programming logic resides in database stored procedures and database functions. I found myself changing the stored proc/functions quite a lot in order to fix bugs or add new functionality. The data (tables) have remained mostly untouched.
The issue I am having is keeping track of versions of stored proc/functions. Currently I am incrementing version of whole database when I do a set of changes. As data is huge (10 Gb) I get issues having to run development version and release versions of databases in parallel.
I wish to put all the stored procs and functions in one database and keep data in one database, so that I can better manage the changes.
I am sure others would have encountered similar suggest and request suggestions on how to best handle this situation.
I would also recommend using source control keyword expansion in your stored procedures ($Version:$)
That way you can eyeball, grep, search syscomments, etc to see what version you have on your deployed database.
You can version just the schema dumps. In combination with source control keword expansion (as suggested by Rawheiser), you just take a look at what version you have in the database, generate a diff and apply it.
Also, there are several excellent tools to compare databases and their schemas, generate DDL scripts etc.: SQL Workbench, Power Architect, DDLUtils and Redgate SQL Compare, to name a few. SQL Compare is likely to work best with SQL Server, although all the others are FOSS and provide a higher ROI (in terms of time spent learning and what you can do with them) as they are platoform and RDBMS independent.
Finally, I have to say...I understand that the immediate results you get with logic in the DB are tempting, but if you've gone beyond more than a couple of procedures in the database, you're setting your self up for quite a lot of pain, sifting through what easily turns into spaghetti code and locking your application to a single database vendor. You might have your reasons, but I've been there and didn't like it very much. Logic can live very nicely in a different layer.
For source control you have several options:
Use a Visual Studio Database project.
Use SQL Server 2005's built-in support for source control
Use a third part tool such as SQL Compare
IMO Option 1. is preferable.
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.