Hi, >> Simply modify a view that has others views depends on (use this one). >> > What I mean is: the actual real world use case. Why do you modify a view? >
Modify a view It's not a use case, it's a routine maintenance task. I can't agree that a view change (without a cascade drop) can accidentally lost other view's source code. That's the worst option. Why don't restrict the drop of a view with dependents or simply invalidate conserving their definition ? ACID it's not limited to a table row. Database purpose is safely store data, metadata and code like views, triggers and UDF source definitions. In any warehouse you have base data model made of tables and relationships that it's hard to change. You use views to produce distinct data sets and calculated columns from the same data model to implement business rules or business views that change much more frequently than base data model. If that data set has an Official Entity status and need to be shared among applications and reports, then you use a view and you must to change it every time their originating business rule/view change. But if you need details, we have a base view to implement official calculations of fixed costs allocations by functional organization units. Then accounting has another view that use this view to make accounting registration grouping information by accounts. Then business analyst has another view that use the to previous views to make results evaluations by branch or business. Any of this views can change from time to time. regards, Dario -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
