stored procedure to create a view

Ok, So i know this questions has been asked. and everything i read has been "well.. you can do it using dynamic DSL, but dont do it" my question is why. I'm still new at this so I'm learning so bear with me but here is what i'm doing. I want to use a stored procedure to create a dynamic view (but not a temporary table) the view has two dates that it uses to establish a beginning and ending date. it looks something like this:

create or replace view MyView as
SELECT
   A.COLUMN_A
   FUNCTION1(to_date('2/10/2011','MM/DD/YYYY') TOTAL1,
   FUNCTION2(to_date('2/15/2011','MM/DD/YYYY') TOTAL2
FROM TABLE_A A;

This view is then used to generate the data needed for a report in crystal. The probl开发者_如何学JAVAem is that we are about to start using these same sql statements in another language. (we are currently using delphi but to about working on another language (but i dont know what the other language is)) the reason I want to create the view in a stored procedure is, because a) the view is dynamic, and based off the date range selected by the user and b) instead of having to put in some rather large views in multiple languages (that have to be created on the fly due to the changing date range selection) onlt the single line for the function and the parameters would need to be passed. Alot of what i read has said that using Dynamic SQL to create a view is bad, but knowing that its already a dynamic view created specifically for the user on the fly, does anyone see an issue with that? I'm asking because I dont want to get myself into something down the road that I wouldnt be able to get myself out of with out wanting to yank all my hair out.

I do Delphi front-ends and SQL Server backends. Why use a view ? I always just create a SP with a simple SELECT which does the job very nicely. If the Crystal Report is used frequently which is usually the case) I simply create a permanent table which is cleared and repopulated each time the SP is run. Short, sweet, and simple.

Generating a view is only a good idea if it's really code-generation and generally fairly permanent. Because it's a schema change, it should be viewed as an advanced technique, and I always try to use database techniques in order of complexity.

i.e. For certain table/view designs, if it can be done with a view, try that. If an indexed view is really needed for performance, try that. Alternatively, maybe a computed column or a persisted computed column. Perhaps an inline table-valued function, or a multi-statement table-valued function, or potentially a stored procedure. So I try to escalate only when necessary.

In your case, that "view" can also be an inline table-valued function in SQL Server (and DB2 at least) and such a creature is just like a parametrized view. You can also use a parametrized stored procedure directly from most reporting tools (and of course from most language/db libraries).

Creating a view (or any database object) dynamically is like manipulating your code at runtime. Powerfull in good and bad ways.

The riscs and problems you might run into:

• performance: DDL statements will invalidate some of your cache, which is bad for performance
• fatal bugs: If other stuff depends on the view (stored procedures, other views ...) they will break if your view breaks for one reason or another.
• scalability: DDL will need a exclusive lock on that object. It might take long to obtain that and blocks everybody else while holding it.
• scalability: What happens if two users need to change the view in different ways at the same time?
• maintainability: It gets hard to understand what is going on when objects change on the fly
• security: Somebody has to have the right to change these objects, which might get misused for doing evil stuff.

In 99.9% one doesn't need dynamic creation of objects and if you aren't in the 0.1 percent you shouldn't use them.

Given your descripton of the task at hand: Why don't you just use the sql statement with the variable parts as bind variables and use that? I don't see the need for a view here.