Where are view constraints useful? By that I mean, Oracle allows a constraint to be created on a view. They are not enforced by the database. It seems to be just more metadata that can be used by the database, but I'm trying to understand under what circumstances they are useful.
Tom Kyte answered in a question:
They are used for complex query rewrites with materialized views and such. It is more "meta data"
-- it gives the optimizer more information, allows for a broader range of query rewriting to take
place.
... but that's a bit brief.
From Oracle Documentation :
View Constraints
You can create constraints on views. The only type of constraint supported on a view is a RELY constraint.
This type of constraint is useful when queries typically access views instead of base tables, and the database administrator thus needs to define the data relationships between views rather than tables. View constraints are particularly useful in OLAP environments, where they may enable more sophisticated rewrites for materialized views.
Quoted another Oracle Documentation page, but never used constraints on views anyway.
Minor use in an Oracle product. In the Designer-generated PL/SQL web applications, components based on views needed a primary key defined on the view. That allowed the application to hyperlink from a list of records to a single-record display.
I remember seeing a few cases with Hibernate where it generated better code when there were PK and FK constraints defined on views. (Can anybody else confirm that?)
And Tom points to query rewrite.
So I think the answer is "if your tools can use the information, then it's better to supply it." Of course, it's going to be hard to figure out which tools will use it.
I try to include them because
It's not much work, though the scripts to recreate views are somewhat more complicated.
It helps in making the physical implementation of the logical model complete
It reminds me of real data constraints that I need to implement somehow, via triggers or background packages or in a "constraint violation" report.
Related
What are the implications (on performance and other aspects) of having Rails Associations between ActiveRecord Models that are not mapped to a Database relationship
I have seen this in a real project and have searched for these implications without any luck
These are some of the documents I have found
http://guides.rubyonrails.org/association_basics.html
http://www.ibm.com/developerworks/library/os-railsn1/
May not be an answer but it would make for a long comment and may add value to the OP.
Correct me if I am wrong but I believe what the OP is getting at is that the code creates the relation but the database does not have a key relationship using foreign and primary keys inside the actual database. Since rails uses Object-Relational (ORM) structure instead of a Database-Relational structure.
Not sure if there are really any draw back implications (although I am sure many would disagree) and the second article seems to focus mostly on n+1 issues which you can resolve by writing appropriate code. Many n+1 issues spring out of code where people do not want to be explicit with their attribute selections and thus rails obliges by returning all attributes of a record. then when you request that objects relationship rails graciously runs another query for you and returns what you've asked for but when you are doing this in large iterations this can cause a large load and create performance issues.
You can avoid these issues by explicitly selecting exactly what you want by using select and group as well as using include or eager_load statements. Yes these are more complicated to write originally as many of them will require more SQL and less railsy syntax but the performance increase can be drastic when querying large tables or multiple relationships.
These are statements you would generally write by hand in stored-procedures or queries in SQL. Rails still gives you these freedoms but many times they are ignored because they look more like SQL than ruby and I have seen more than once people complaining about both the fact that if they change the DB they will have to change this too and that it "looks bad". Well if you were writing this from scratch in a standard database both these issues still apply.
As many have stated "ORM is just a tool" and any tool that is used improperly can have drastic implications. As long as you understand the tools you are using ORM can be very powerful and far more concise but if you ignore features your tool provides expect to have consequences with an extensive reach.
If you use a chainsaw as a hammer expect to lose an arm
UPDATE
I am unaware of any improvements in performance due to relationships inside the database other than it offers a hint as to where to index values. (You can create indexes during rails migrations although the primary ones are created for you the relational ones generally are not). Adding indexing to relational fields will generally speed up the database performance whether or not the specific relationship is actually defined in the database. Someone Asked a Similar Question
Database Relationships are more about Data Integrity than anything else and these issues should be handled inside your models in an ORM design not in the database its self.
Here is another resource to take a look at
And a few more SO questions on the subject
In SQL Server 2008, do relationships make queries faster?
Does Foreign Key improve query performance?
What's wrong with foreign keys?
Is there a severe performance hit for using Foreign Keys in SQL Server?
SQL Server Foreign Key constraint benefits
You get the idea just about asking the right question.
I am new to oracle and i wanted to know if materialized views can be created on top of views. I also need a column in the mview that has a complex calculation for which I am thinking of writing a function.
There are materialised views, and then again there are materialised views.
By which I mean that the capabilities of the materialised view can vary greatly with respect to query rewrite and refreshability according to the exact nature of the tables (or views) that it references, and according to their properties.
So although you might be able to create an MV that references a view, whether it is useful to you or not is a matter that depends on a great many other issues.
I find that the documentation can sometimes be unclear, particularly in edge-cases, and the best approach is generally to create the MV and then to test its capabilities using Oracle built-in procedures -- here's a link to DBMS_MView for 10.2 http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_mview.htm#CEGGEHHC
I'm working on migrating application from Access to Oracle and have faced with a strange issue . So we have a regular oracle schema - nothing fancy. on the top of that schema I created a number of views - approximately 15. These views use each other and dependency tree can be deep - I'd say up to 6-8 levels.
So now I faced with an issue when I cannot create another view - CPU at oracle servers goes to 50% when I execute 'create or replace view' statement and it takes forever. Views are right now in such a state that selection data from these views may take time, but the issue appears in 'create' statement. I'm not using 'select * ...' in the views and the problematic view depends just on two others.
I'm using Oracle 10g Enterprise v 10.2
In SQL Server I'm familiar with Profiler and would do a trace, view schema locks, but I don't know Oracle that much.
Will appreciate any hints. Thank you.
Views referencing views referencing views strikes me as highly unnecessary. I know we're all supposed to be in favour of "don't repeat yourself" but DRY is a guideline, not a cast-iron rule. It's certainly not intended to be applied so compactly in a database context that nothing compiles.
So try separating out all the views, so that each one references only tables in the FROM clause. That should solve your problem and allow you to make progress with your code.
You can always review the situation later. The neat thing about a view is that it is just an interface. If you subsequnetly want to refactor some views, to replace tables with views than you will be able to, with the minimum of inconvenience (unless you re-introduce the compilation hang).
My latest project deals with a lot of "staging" data.
Like when a customer registers, the data is stored in "customer_temp" table, and when he is verified, the data is moved to "customer" table.
Before I start shooting e-mails, go on a rampage on how I think this is wrong and you should just put a flag on the row, there is always a chance that I'm the idiot.
Can anybody explain to me why this is desirable?
Creating 2 tables with the same structure, populating a table (table 1), then moving the whole row to a different table (table 2) when certain events occur.
I can understand if table 2 will store archival, non seldom used data.
But I can't understand if table 2 stores live data that can changes constantly.
To recap:
Can anyone explain how wrong (or right) this seemingly counter-productive approach is?
If there is a significant difference between a "customer" and a "potential customer" in the business logic, separating them out in the database can make sense (you don't need to always remember to query by the flag, for example). In particular if the data stored for the two may diverge in the future.
It makes reporting somewhat easier and reduces the chances of treating both types of entities as the same one.
As you say, however, this does look redundant and would probably not be the way most people design the database.
There seems to be several explanations about why would you want "customer_temp".
As you noted would be for archival purposes. To allow analyzing data but in that case the historical data should be aggregated according to some interesting query. However it using live data does not sound plausible
As oded noted, there could be a certain business logic that differentiates between customer and potential customer.
Or it could be a security feature which requires logging all attempts to register a customer in addition to storing approved customers.
Any time I see a permenant table names "customer_temp" I see a red flag. This typically means that someone was working through a problem as they were going along and didn't think ahead about it.
As for the structure you describe there are some advantages. For example the tables could be indexed differently or placed on different File locations for performance.
But typically these advantages aren't worth the cost cost of keeping the structures in synch for changes (adding a column to different tables searching for two sets of dependencies etc. )
If you really need them to be treated differently then its better to handle that by adding a layer of abstraction with a view rather than creating two separate models.
I would have used a single table design, as you suggest. But I only know what you posted about the case. Before deciding that the designer was an idiot, I would want to know what other consequences, intended or unintended, may have followed from the two table design.
For, example, it may reduce contention between processes that are storing new potential customers and processes accessing the existing customer base. Or it may permit certain columns to be constrained to be not null in the customer table that are permitted to be null in the potential customer table. Or it may permit write access to the customer table to be tightly controlled, and unavailable to operations that originate from the web.
Or the original designer may simply not have seen the benefits you and I see in a single table design.
IF a create thousands of view, Does it hamper the database performance. I mean is there any problem with creating thousands of view in oracle. Please explain as I am new in this area...I am using oracle...
The simple existence of these views shouldn't harm performance at all. However, once those views start being used it's possible that there will be some negative performance impact. Oracle tries to "remember" the plan for each statement that it sees, but it compares statements by comparing the source code (the SQL). Your thousands of views will all be named differently since you can't have multiple views with the same name, and thus each time one of them is used Oracle is going to have to do a full parse of the SQL, even if it's something as basic as
SELECT * FROM VIEW_1;
and
SELECT * FROM VIEW_2;
All these re-parses will certainly take some time.
What's different about each of these views? I think it might be a good idea to step back and consider other possibilities. Questions I'd ask include
What is to be accomplished here?
Why are thousands of different views needed?
Is there some other way to accomplish what needs to be done without creating all these views?
I don't know the answers to 1 and 2, but I'm reasonably sure that the answer to #3 is "Yes".
Good luck.
Oracle views are an encapsulation of a
complex query and must be used with
care. Here are the key facts to
remember:
Views are not intended to improve SQL
performance. When you need to
encapsulate SQL, you should place it
inside a stored procedure rather than
use a view. Views hide the complexity
of the underlying query, making it
easier for inexperienced programmers
and end users to formulate queries.
Views can be used to tune queries with
hints, provided that the view is
always used in the proper context.
source: Guard against performance issues when using Oracle hints and views
View is as heavy to run as the select that creates it but Oracle loads balance and single select can't harm the DB. If you have thousands concurrent selects going then you might have a problem. The amount of views is not important but how heavy they are and how much you use them.
You would actually need to show the views code and tell what you are actually trying to do.
View should not affect performance, if optimizer is smart enough. I remember cases with other DB engines when Views do harm performance. As in many performance cases - I suggest to measure your particular case.