view- какво е рпедимството???

Какви са предимствата и недосттъците на view пред обикновена селецт заявка? (Firebird 1.5.2, но това едва ли е от голямо значение, интересува ме концепцията - кога да използвам view-та)

да кажем че вместо да пишеш сложна заявка обхващаща данни от няколко таблици можеш да си създадеш изглед съдържащ необходимите ти полета от тези таблици и да изпълняваш прости заявки върху тях.

------------------------

Кой ли пък съм аз?

Ако искаме определени юзъри да виждат само определени записи от една таблица - ето ти за какво е view-то. В него слагаш подходящия филтър, а на юзърите даваш права върху view-то, а не върху таблицата която чете view-то.

та това може да се постигне и с парсер на заявките, през който да минават всички заявки, използвани в приложението и да им добавя различни условия за права, филтри и т.н.т
Във firebird не използвах вю-та, заради невъзможността да се викат съхранени процедури от тях.

Аз пробвах едно view :
CREATE VIEW NEW_VIEW(
ID, NAME)
AS
select T1.ID, T1.name
from Table1 T1
и всичко е ок. После го модифицирах малко, като добавих още една таблица:
CREATE VIEW NEW_VIEW(
ID, NAME, T2_ID)
AS
SELECT T1.ID, T1.NAME, T1.T2_ID
FROM Table1 T1
JOIN Table2 T2 ON T1.T2_ID=T2.ID - SELECT-a то view-то си е наред (мога и да добавям записи), обаче :
INSET INTO NEW_VIEW (ID, NAME, T2_ID)
values ("111","MMM","000") => "The object of the insert, delete or update statement is a view for which the requested operation is not permitted.
cannot update read-only view NEW_VIEW.", като в T2 имам запис с ID="000"!!!
Това значи ли, че ако съм JOIN-ал поне една таблица, не мога да инсъртвам във VIEW-to? А това с правата за достъп - аз съм ги задал в самото приложение, конкретно към NickBass- може би има по-добър вариант, директно във SQL-Servera (в случая - firebird 1.5.2)?? Какво имаш в предвид под "подходящ филтър във view-то?)

Значи.

При различните реализации има различни ограничения за Update, Insert и Delete, когато се използват Изгледи

В отговор на:

---

Това значи ли, че ако съм JOIN-ал поне една таблица, не мога да инсъртвам във VIEW-to?

---

Не, не значи. За да си направиш обновяемо вю-то трябва да му добавиш тригер before update

В отговор на:

---

А това с правата за достъп - аз съм ги задал в самото приложение

---

Това не ти решава проблема при достъп от приложения от други разработчици
Идеята на NickBass е, че можеш да управляваш правата на достъп до отделни записи на ниво база данни, без значение, какво приложение се ползва. В комбинация с тригерите, ти дава възможност и да управляваш и правата за ъпдейт на отделни записи.

Я поясни малко.

Това което казваш за Тригерите само за Firebird ли се отнася?

Според стандарта в някои случаи е допустимо да имаш updatable view декларирано с join, а в други не.

Updatable view обаче няма нищо общо с никакви тригери по дефиниция. Или сървърът го може или не.

Ето един пример:

mysql> select * from t1;
+------+------+
| id | n |
+------+------+
| 1 | a |
| 2 | b |
+------+------+
2 rows in set (0.00 sec)

mysql> select * from t2;
+------+-------+
| id | t1_id |
+------+-------+
| 99 | 1 |
| 23 | 2 |
+------+-------+
2 rows in set (0.00 sec)

mysql> create view vv as select t1.id, t1.n, t2.id as t2_id from t1, t2 where t1.id = t2.t1_id;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from vv;
+------+------+-------+
| id | n | t2_id |
+------+------+-------+
| 1 | a | 99 |
| 2 | b | 23 |
+------+------+-------+
2 rows in set (0.00 sec)

mysql> update vv set n = 'xyz' where t2_id = 23;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from vv;
+------+------+-------+
| id | n | t2_id |
+------+------+-------+
| 1 | a | 99 |
| 2 | xyz | 23 |
+------+------+-------+
2 rows in set (0.00 sec)

mysql> select * from t1;
+------+------+
| id | n |
+------+------+
| 1 | a |
| 2 | xyz |
+------+------+
2 rows in set (0.00 sec)


Обаче:
mysql> update vv set n = 'abcd', t2_id = 1234 where t2_id = 23;
ERROR 1393 (HY000): Can not modify more than one base table through a join view 'bugs.vv'

salle.online.bg/sig

CREATE TABLE T1 (

    ID  INTEGER NOT NULL,

    N   VARCHAR(10)

);

ALTER TABLE T1 ADD CONSTRAINT PK_T1 PRIMARY KEY (ID);



CREATE TABLE T2 (

    ID     INTEGER NOT NULL,

    T1_ID  INTEGER

);

ALTER TABLE T2 ADD CONSTRAINT PK_T2 PRIMARY KEY (ID);

ALTER TABLE T2 ADD CONSTRAINT FK_T2 FOREIGN KEY (T1_ID) REFERENCES T1 (ID);



INSERT INTO T1 (ID, N) VALUES (1, 'a');

INSERT INTO T1 (ID, N) VALUES (2, 'b');



INSERT INTO T2 (ID, T1_ID) VALUES (99, 1);

INSERT INTO T2 (ID, T1_ID) VALUES (23, 2);



CREATE VIEW VV(

    T1ID,

    T1N,

    T2ID)

AS

select t1.id, t1.n, t2.id

    from t1, t2

    where t1.id = t2.t1_id

;



select * from vv;

T1ID	T1N	T2ID

1	a	99

2	b	23

без тригер

update vv set t1n='x',t2id=66  where t1id=1;

The object of the insert, delete or update statement is a view for which the 

requested operation is not permitted.

cannot update read-only view VV.

създаваме тригер (какъв е смисъла в случая е без значение)

CREATE TRIGGER VV_BU0 FOR VV

ACTIVE BEFORE UPDATE POSITION 0

AS

begin

update t1 set n=new.t1n where id=new.t1id;

update t2 set ID=new.t2id where id=OLD.T2ID;

end

и вече можем да правим ъпдейт

update vv set t1n='x',t2id=66  where t1id=1;

1 record(s) was(were) updated in T1

1 record(s) was(were) updated in T2



select * from vv;

T1ID	T1N	T2ID

1	x	66

2	b	23

Firebird 1.5.2.4731

Нека постгресаджиите да кажат при тях как е

може и с тригер, но при postgresql има нещо доста нестандартно наречено RULE с него става доста елегантно

[линк]

предимството на тези методи с тригери и рулове е, че може всевъзможни вюта да се направят updatable, а не само тези, за които базата измисли как да ги нарпави

за предимство на view-то горе-долу са ги казали - удобство ... основно за ползване на сложни заявки и за добавяне на сигурност

скоростта на обработване на view може да се мени и към забавяне и към ускоряване в зависимост от базата и зависимост от конкретното view и начина му на извикване (т.е. тва хем може да е плюс хем минус, но когато е плюс в общия случай е малък плюс, а когато е минус може да бъде голям минус :-) защото може да доведе до ползване на калпав план на заявката, но това би трябвало да са изключения, но реални :-))))

Много е гот е когато някой точно те разбира какво имаш предвид.

>А това с правата за достъп - аз съм ги задал в самото приложение

В клиент-сървър системите сървъра за какво е? Твоето приложение е клиента, а всъщност се прави на сървър. Представи си, че имаш таблица със записи, някои от които трябва да бъдат виждани само от определени юзъри. Например - доставните цени на стоките трябва да се виждат само от някои хора, щото иначе на шефа какво ще му чуят ушите? Ако твоето приложение "администрира" достъпа на непривилегированите като генерира заявка:
SELECT
PRICE_ID, PRICE_TYPE, PRICE
FROM
ARTICLE_PRICES
WHERE
PRICE_TYPE <> 'DOSTAVNA';
то тогава тази заявка може да се пусне от всякаква SQL конзола от човек, който просто си е направил труда да прочете какво е SELECT и има ли то почво у нас... Без WHERE клаузата "секретната" информация е разкрита.

>, конкретно към NickBass- може би има по-добър вариант, директно във SQL-Servera (в случая - firebird 1.5.2)?? Какво имаш в предвид под "подходящ филтър във view-то?)

CREATE VIEW V_ARTICLE_PRICES(
PRICE_ID,
PRICE_TYPE,
PRICE)
AS
SELECT
P.PRICE_ID,
P.PRICE_TYPE,
P.PRICE)
FROM
ARTICLE_PRICES P
WHERE
(P.KEY_R IS NULL) OR
(P.KEY_R =
(
SELECT U.KEY_CODE
FROM USERKEYS U
WHERE (U.USER_NAME = CURRENT_USER) AND (U.KEY_CODE = P.KEY_R)
)
)
;

Не ти поствам цялата структура. Айде сети се сам Ако не - питай.