I am dealing with a software vendor who insisted that view is behaving differently from a physical table. The system is having error and they blame us for using view than the physical table.
Is this true? I'm using SQL2008R2. It will be helpful also if there is a strong reference to proof it. Thank you.
It might be behaving differently if the view makes an aggregation or if the view combines several tables or does anything else apart from just showing the original table.
If your view is created as
create view my_view as select * from my_table
there is no difference in behaiviour or data
But if your view is created for example as
create view my_view as select * from my_table inner join other_table on ...
there might be differences because of potencial data loose in the join.
Hope it helps.
The bytes returned to the application are the same irrespective of what internal structure SQL Server used to obtain them.
Related
I use PostgreSQL10 and I want to built queries that have multiple optional parameters.
A user must input area name, but then it is optional to pick none or any combination of the following event, event date, category, category date, style
So a full query could be "all the banks (category), constructed in 1990 (category date) with modern architecture (style), that got renovated in 1992 (event and event date) in the area of NYC (area) ".
My problem is that all those are in different tables, connected by many-to-many tables, so I cannot do something like
SELECT * FROM mytable
WHERE (Event IS NULL OR Event = event)
I dont know if any good will come if I just join four tables.
I can easily find the area id, since it is required, but I dont know what the user chose, beside that.
Any suggestions on how to approach this, with Postgre?
Thanks
It might be optimal to build the entire query dynamically and only join in tables that you know you're going to need in order to apply the user's filters, but it's impractical. You're better off creating a view on the full set of tables. Use LEFT OUTER JOINs to ensure that you don't accidentally filter out valid combinations and index your tables to ensure that the query planner can navigate the table graph quickly. Then query the view with a WHERE clause reflecting only the filters you want to apply.
If performance becomes a concern and you don't mind having non-realtime data, you could use a materialized view to cache the results. Materialized views can be indexed directly, but this is a pretty radical change so don't do this unless you have to.
I am using PostgreSQL for GIS purposes with PostGIS and QGIS, but I think I might find more informations here than on gis.stackexchange.com since my question is not directly GIS related.
I am using views to diplay datas at will for the specific needs of my users, like that they have access to the datas as they are in the DB, but with just what they need. I added some rules to my views to make them "updatable" in QGIS and make them directly "workable" by the users.
Display in QGIS is based on attributes, but since there is the possibility that different persons will access the same data at the same moment, and they might want to display and hide some of these datas according to their needs (map printing for once). So I am looking for a way to give possibility to have a specific display for each view, and I thought about simply adding a "virtual" column in the view definition, with for example a boolean like such:
CREATE VIEW view1 AS
SELECT oid, column1, True as display from table1;
But I would like my users to be able to change the value of this column, to simply make appear or disappear the objects from the canvas (with a ruled-base styling considering this parameter). And obviously it doesn't work direclty since the update would be in conflict with the definition of the view.
Does anyone have any idea on how to achieve that? Maybe a materialized view (but I quite like the dynamics of the regular view)?
Thanks.
If the unique ID field is read from the table (i.e. it is not dynamically created via the row_number() trick commonly used with spatial views in QGIS), you could create a visibility manager table and use it in the view. You could have one table by view or one for all of them. Something similar to:
create table visibility_manager (oid bigint, visibility_status boolean, viewname text);
CREATE VIEW view1 AS
SELECT table1.oid, column1, coalesce(visibility_status,true) as display
from table1
left outer join visibility_manager
on (table1.oid = visibility_manager.oid and visibility_manager.viewname = 'view1');
see it in action:
http://rextester.com/OZPN1777
I am using Postgres Version 9.1 and am having some trouble reviewing past VIEWS that I have created.
Once I create a VIEW, Postgres jumbles up the CREATE VIEW text so it is very unreadable.
For instance, I might create a simple VIEW as:
create view some_view as
select *
from some_table
where some_column = 'some_value';
This then turns into something way more complicated as:
select [all columns...]
from some_table
where (((some_column = 'some_value')));
Now, this is a simple example - however when you get into multiple JOINS and WHERE clauses or SUBQUERIES it gets nearly impossible to read so as to edit the VIEW at a later date.
(The exact location the VIEWS are stored is in information_schema.pg_views if anybody cares to look.)
For that reason I save my CREATE VIEW scripts as a separate .sql file, however this can get taxing and is obviously has the liability of not being sync'd with the current VIEW in the Postgres Database (if you update the VIEW but don't update the .sql file for instance).
It would be MUCH more simple if the plain text of the CREATE VIEW was saved.
When I create a FUNCTION, it saves the script entirely as is with all white-space, etc.
This makes it very simple, at a later date, to review it and see if it needs to be fixed up or spot possible errors.
So my question is if there is some place in the Postgres database where the actual plain-text is saved of the CREATE VIEW statement for later review/editing.
Thank you.
As found, the correct answer is to:
a) Maintain your SQL Scripts in separate files
b) Have a proper versioning system (Git, etc.)
c) Deploy from the versioning system
Done Deal.
I have arrived at this dilemma via a tortuous and frustrating route, but I'll start with where I am right now. For information I'm using VS2010, Silverlight 5 and the latest versions of the Silverlight and RIA Toolkits, SDKs etc.
I have a view in my database (it's actually now an indexed view, but that has made no difference to the behaviour). For testing purposes (and that includes testing my sanity) I have duplicated the view as a Table (ie identical column names and definitions), and inserted all the view rows into the table. So if I SELECT * from the view or the table in Query Analyzer, I get identical results. So far so good.
I create an EDF model in my Silverlight Business Application web project, including all objects.
I create a Domain Service based on the model, and it creates ContextTypes and metadata for both the View and the Table, and associated Query objects.
If I populate a Silverlight ListBox in my Silverlight project via the Table Query, it returns all the data in the table.
If I populate the same ListBox via the View Query, it returns one row only, always the first row in the collection, however it is ordered. In fact, if I delve into the inner workings via the debugger, when it executes the ObjectContext Query in the service, it returns a result set of the correct number of rows, but all the rows are identical! If I order ascending I get n copies of the first row, descending I get n copies of the last row.
Can anyone put me out of my misery here, and tell me why the View doesn't work?
Ade
OK, well that was predictable - nearly every time I ask a question on a forum I stumble across the answer while I'm waiting for responses to flood in!
Despite having been through the metadata and model.designer files and made sure that all "view" and "table" class/method definitions etc were identical, it was still showing the exasperating difference in behaviour between view and table queries. So the problem just had to be caused by the database, right?
Sure enough, I hadn't noticed myself creating NOT NULL columns when I created the "identical" Table version of my view! Even though I was using a SELECT NEWID() to create a unique key column on the view, the database insisted that the ID column in the view was NULLABLE, and it was apparently this which was causing the problem.
To save some storage space I switched from using NEWID() to using ROW_NUMBER() to create my key column, but still had the "NULLABLE" property problem. SO I then changed it to
SELECT ISNULL(ROW_NUMBER() (OVER...) , -1)
for the ID column, and at last the column in the view was created NOT NULL! Even though neither NEWID() nor ROW_NUMBER() can ever generate NULL output, it seems you have to hold SQL Server's hand and reassure it by using the ISNULL operator before it will believe itself.
Having done this, deleted/recreated my model and service files, everything burst into glorious technicolour life without any manual additions of [Key()] properties or anything else. The problem had been with the database all along, and NOT with the Model/Service/Metadata definitions.
Hope this saves someone some time. Now all I need to do is work out why the original stored procedure method I started with two days ago doesn't work - but at least I now have a hint!
Ade
I'd like call function within a view to resolve virtual column. Calculating depends on data in actual row and did not want to multiple times selecting a data. Is this correct?? And like bonus, is possible call function within a call another?
CREATE VIEW my_view AS SELECT c.column1,c.columns2,... my_function(c) FROM my_table c
CREATE VIEW my_view AS SELECT c.money, c.quantity,... my_ratio_function(c.money,c.quantity,select sum_all_pays(my_view)) FROM my_table c
note. I'm put here because when looked for, cannot find that. If you have any other ideas, put it. Second one command not sure if is correct.
It is fine to use functions in the view definition. The only constraint — you should always give an explicit name to the column that is actually a function call, otherwise PostgreSQL doesn't know how to present a view definition.
Still, you cannot reference the view from inside the view. Instead, you might create 2 views, then you can reference the inside one from the outside view. Another approach is to use the WITH construct, which I find very handy and do use a lot.
Please note, that view is just a server-stored SQL and functions will be called for each row each time you will be querying the view. To get some performance improvements you might want to define your functions either as IMMUTABLE or as STABLE.
And I do agree with Frank — go ahead and test your views.