In Transact-SQL for Azure SQL Database, is there any facility in stored procedures or user-defined functions to include or reference another unit to get common definitions? I frequently cut and paste variables used as constant definitions between procedures and am looking for a better way. I am aware of user-defined table types.
From comment by TT: No. T-SQL by itself has no such concept.
Related
I am using Postgres for microservice backends and the databases are designed to be small(ish) and simple.
We have four schemas in our databases:
live: all the functions, tables, etc used by the application
utest:unit tests
testframe: unit testing functions/framework
testdata: functions that create common test data
When the database is shipped to production ONLY the 'live' schema is retained, all the testing schema's are dropped.
So my question is: Is there any reason for functions in the 'live' schema to explicitly using the 'live.' schema prefix when referring to tables and calling other functions?
After much googling I am having a hard time making an argument for explicitly using the schema prefix.
Thanks, any comments are appreciated.
Always qualifying objects with their schema names is a good way of making sure that no other objects with the same name in other schemas can be used by mistake. For example, the pg_catalog schema is always on your search_path, so system objects might be chosen.
Is it possible to get the table structure like db2look from SQL?
Or the only way is from command line? Thus, by wrapping a external stored procedure in C I could call the db2look, but that is not what I am looking for.
Clarification added later:
I want to know which tables have the non logged option from SQL.
It is possible to create the table structure from regular SQL and the public DB2 catalog - however, it is complex and requires some deeper skills.
The metadata is available in the DB2 catalog views in the SYSCAT schema. For a regular table you would first start off by looking into the values in SYSCAT.TABLES and SYSCAT.COLUMNS. From there you would need to branch off to other views depending on what table and column options you are after, whether time-travel tables, special partitioning rules, or many other options are involved.
Serge Rielau published an article on developerWorks called Backup and restore SQL schemas for DB2 Universal Database that provides a set of stored procedures that will do exactly what you're looking for.
The article is quite old (2006) so you may need to put some time in to update the procedures to be able to handle features that were added to DB2 since the date of publication, but the procedures may work for you now and are a nice jumping off point.
I have several table-valued overloaded procedures in my PostgreSql database. They have the same name, but different number of parameters. As JOOQ 3.5 treats those procedures as tables, generator discovers only one procedure with that name. Is it designed this way, or is there a workaround?
GeneratorStrategy doesn't help as this happens earlier, when database.getTables(schema) in Generator is Called.
This is a bug (#4055) in jOOQ 3.5.2. jOOQ currently doesn't support overloaded table-valued functions.
The only workaround I can think of is to resort to plain SQL for those functions.
How do I use Slick to call a stored procedure?
I want it to be type safe / injection safe. (ie, I don't want any SQL query strings in my code...)
According to the docs, Slick includes "Type-safe support of stored procedures" (http://slick.typesafe.com/doc/1.0.0/introduction.html)
But I do not see any example in the docs of how to do it.
That's a typo. It should read "Type-safe support of scalar database functions". At the moment you have to use plain SQL to call stored procedures.
Also see https://groups.google.com/forum/#!searchin/scalaquery/procedure/scalaquery/BUB2-ryR0bY/EFZGX663tRYJ
I want to know what PostgreSQL functions are.
When do I have to write them?
How can I write them?
And how can I call them?
Definition, from wikipedia:
A stored procedure is a subroutine available to applications that
access a relational database system.
Advantages of stored procedures in general, from wikipedia:
Overhead: Because stored procedure statements are stored directly in
the database, they may remove all or part of the compilation overhead
that is typically required in situations where software applications
send inline (dynamic) SQL queries to a database. (...)
Avoidance of network traffic: A major advantage with stored procedures
is that they can run directly within the database engine. In a
production system, this typically means that the procedures run
entirely on a specialized database server, which has direct access to
the data being accessed. The benefit here is that network
communication costs can be avoided completely. This becomes
particularly important for complex series of SQL statements.
Encapsulation of business logic: Stored procedures allow programmers
to embed business logic as an API in the database, which can simplify
data management and reduce the need to encode the logic elsewhere in
client programs. (...)
Delegation of access-rights: In many systems, stored procedures can be
granted access rights to the database that users who execute those
procedures do not directly have.
Some protection from SQL injection attacks: Stored procedures can be
used to protect against injection attacks. Stored procedure parameters
will be treated as data even if an attacker inserts SQL commands. (...)
In PostgresSQL stored procedures are called user defined functions.
Definition example:
CREATE FUNCTION somefunc(quantity integer) RETURNS integer AS $$
DECLARE
myvariable integer := 2;
BEGIN
RETURN quantity * myvariable;
END;
$$ LANGUAGE plpgsql;
(You can use other languages to define stored functions in PostgreSQL)
Calling example:
SELECT somefunc(100);
More info: http://www.postgresql.org/docs/9.1/static/server-programming.html
PostgreSQL runs stored procedures in more than a dozen programming languages, including Java, Perl, Python, Ruby, Tcl, C/C++, and its own
PL/pgSQL, which is similar to Oracle's PL/SQL.
The use of stored procedure depends on your needs and depends on the logic of your program, in my opinion stored procedure are useful only in some cases and not ever...
I've used stored procedure in a multi database server application, in this case the use of stored procedure could be extremely useful for example in the case you have a query that need to be modified for run in another database server type, in that case you can write a stored procedure in each database server and call it from your program being sure that it run and retrieve the wanted resultset without any changes in the client code.
To learn how to create stored procedure in PostgreSQL refer to this page of the documentation.
the main advantage is reducing network traffic overhead. Stored procedure is almost same (not exactly) as business logic or logic tire. Its main advantage is making dynamic enterprise application.You can find 100s of good product failed just because lack of dynamic database structure. Stores procedures,Functions,Triggers,Sequences,indexes and relational nature of database are the real keys to create great applications.My company always try to reduce client side logic layers with the help of stored procedures. Most of the critical logics are store in stored procedures which makes programmers and testers happy and meet their timelines.