Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Нет не улавливаю. Вот если бы в реализации C++ от Борланд не было мн.насл., то я бы тоже объявил это багом.


Понимаете, баг называют багом не по вашему желанию, а только в том случаи, если поведение какой-либо системы отличается от документированного.

hvlad
Это баг. Я не могу использовать VIEW + INSTEAD OF триггер по назначению - скрыть логику от конечного приложения.


Опять - 25! Используйте, но выполняйте требования СУБД с которой работаете. Да, нельзя в MS SQL в представление с триггером INSTEAD OF не передавать ничего в поле, которое в базовой таблице NOT NULL:

BOL
Columns in the view select list can be nullable or not nullable. If a view column does not allow nulls, an INSERT statement must provide values for the column.


Вариантов "обхода" - море, например, заведение DEFAULT CONSTRAINT и использования клаузы DEFAULT в инструкции INSERT.

Более того, для того, чтобы "скрыть логику от конечного приложения" использование "VIEW + INSTEAD OF" не единственное верное решение. (Об этом чуть позже).

hvlad
Читаю, просто читаю. Низзя ?


Есть другие способы "читания" текстов хп, триггеров и функций, отличных от прямого доступа к системным таблицам с их якобы "кривизной".

hvlad
Из-за убогости поставляемого клиентского утиля, я, вплоть до MSSQL2K, пользовался редактором кода Дельфи для написания процедур. В MSSQL2K хоть синтаксис подсвечивается в Query Analyzer'е :)


У меня возникает подозрение, что Вы не пользовались "клиентским утилем" версий до 2К, ибо подсветка синтаксиса была и там.

hvlad
Та написал, написал :)
Угу, не этим. А возможностями триггеров, в частности


И Вы не один такой, который написали. А на счет возможности триггеров, по-моему, я уже не один раз написал, что "VIEW + INSTEAD OF" не единственное верное решение.
5 июл 06, 09:36    [2843471]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Gluk (Kazan)

Бу га га открылась страшная тайна
так вот почему в MS SQL нет пакетов :)

Сейчас все пользователи MS SQL помрут от отчаяния по этому поводу :)
5 июл 06, 09:46    [2843512]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
iscrafm
Gluk (Kazan)

Бу га га открылась страшная тайна
так вот почему в MS SQL нет пакетов :)

Сейчас все пользователи MS SQL помрут от отчаяния по этому поводу :)


Ну на счет всех не знаю, а мы слегка уже затрахались на портации потрошить пакеты в отдельные процедуры (их получается довольно много, да и логика взаимодействия местами не тривиальна).
Собственно моя реплика имела смысл: "Не надо притягивать за уши статистику (к тому же спорную) там где достаточно сказать - так было удобнее разработчикам"
Кстати, каков средний размер хранимок на .Net ?

автор
Опять - 25! Используйте, но выполняйте требования СУБД с которой работаете. Да, нельзя в MS SQL в представление с триггером INSTEAD OF не передавать ничего в поле, которое в базовой таблице NOT NULL:


А какой смысл в таких триггерах ? Вы предлагаете решать задачу другими средствами, но есть ли какая-то задача, которую удобно решать этим средством ?
5 июл 06, 10:13    [2843683]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Gluk (Kazan)
Ну на счет всех не знаю, а мы слегка уже затрахались на портации потрошить пакеты в отдельные процедуры (их получается довольно много, да и логика взаимодействия местами не тривиальна).

Лучше подходить с другого конца. Раскладывать логику на тривиальные процедуры. В этом и есть задача проектирования. Иначе никаких фич субд может не хватить.
5 июл 06, 10:31    [2843795]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Gluk (Kazan)

автор
Опять - 25! Используйте, но выполняйте требования СУБД с которой работаете. Да, нельзя в MS SQL в представление с триггером INSTEAD OF не передавать ничего в поле, которое в базовой таблице NOT NULL:


А какой смысл в таких триггерах ? Вы предлагаете решать задачу другими средствами, но есть ли какая-то задача, которую удобно решать этим средством ?


А какой смысл в BEFORE триггерах тогда? INSTEAD OF это практически тоже самое что и BEFORE. Просто NOT NULL проверяется почему-то перед триггером, остальные CONSTRAINTы не проверяются. Обходится, как показано, элементарно, никаких других средств использовать не надо.
Странное решение разработчиков конечно, но не баг всё же.
5 июл 06, 10:56    [2843934]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
iscrafm
Лучше подходить с другого конца. Раскладывать логику на тривиальные процедуры.

Угу. Мне вспоминается первый серьезный проект, с которым довелось работать - он состоял из нескольких десятков тысяч .c-файлов, в каждом из которых было по одной функции. Причина этого была в том, что линковщик не умел выбирать нужные функции и гнал в exe-шник весь obj-файл целиком; соответственно, при компиляции проекта из кучи exe приходилось либо разбивать таким образом, либо получать в exe кучу неиспользуемого кода. Имя файла, разумеется, совпадало с именем функции, поэтому имена функций были не длиннее восьми символов. Такая вот "задача проектирования".
5 июл 06, 10:57    [2843941]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
И это один из недостатков Delphi.


Не спорю. Но это не называют "багом" Delphi или "неправильным" поведением. Это AS IS или by design и с эитм приходится работать.

softwarer
По моим ощущениям, Вы вскипели несколько зря, особенно если учесть, что мне по этому же поводу, если только не изменяет память, Вы ответили несколько иначе. Я не вижу, чтобы Ваш собеседник "объявлял абсолютно неправильным"; насколько я вижу, он всего лишь сказал, что не стоит объявлять подход, существенно снижающий ценность механизма updateable view, единственно правильным.


Я и не "вскипал", а высказал свою точку зрения по поднятому вопросу в различии поведения СУБД. и Вам я ответил, что:

pkarklin
Не исключаю, такой функционал может быть необходим и его стоит "требовать" реализовать от разрабочиков MS SQL.


Но, тем не менее, его отсутствие, никак не делает поведение СУБД "неправильным".

На счет "абсолютно" - согласен, собеседник объявил его просто "неправильным", приведя реализацию такого подхода в "правильной СУБД".

На счет ценности механизма. Совершенно не согласен с Вами, что "наследование" метаданных базовых таблиц является "существенным" снижением ценности механизма updateable view. Отличия в поведении механизма в разных СУБД есть, но не более того. Варианты "прерывания наследования" или способов его использованя в описанной реализации были приведены.

pkarklin
И? by design - это аргумент из серии "это не ошибка, это системная функция".


Это ожидаемое поведение! И называть такое поведение ошибкой, даже если оно отличается от поведения аналогичного механизма в другой СУБД, IMHO, не совсем корректно.

softwarer
Существует стандартный подход - триггера срабатывают до проверки ограничений. Это позволяет легко и приятно решать многие задачи; скажем, мне было бы любопытно посмотреть на не использующее этого подхода нормальное решение следующей простой задачи:
...
Насколько я понимаю, в рассматриваемом случае этот принцип нарушается. Что ж, жаль. Еще один факт в копилку утверждения о том, что подход "все на процедурах" базируется не столько на хорошести процедур, сколько на слабости прочих механизмов в конкретном случае.


Странно, однако, требовать от СУБД, не имеющих BEFORE триггеров аналогичности в поведении.

create table tt1 (i int not null primary key)
GO
create table tt2 (i int not null primary key)
GO
alter table tt1 add constraint FK_tt1_tt2 foreign key (i) references tt2 (i)
GO
alter table tt2 add constraint FK_tt2_tt1 foreign key (i) references tt1 (i)
GO
CREATE PROC insert_tt1_tt2
AS
  SET NOCOUNT ON
  SET XACT_ABORT ON
  BEGIN TRAN
    ALTER TABLE tt1 NOCHECK CONSTRAINT FK_tt1_tt2
    ALTER TABLE tt2 NOCHECK CONSTRAINT FK_tt2_tt1
    INSERT INTO tt1
    SELECT number FROM master..spt_values WHERE type = 'P' AND number BETWEEN 1 AND 10
    INSERT INTO tt2
    SELECT number FROM master..spt_values WHERE type = 'P' AND number BETWEEN 1 AND 10
    ALTER TABLE tt1 CHECK CONSTRAINT FK_tt1_tt2
    ALTER TABLE tt2 CHECK CONSTRAINT FK_tt2_tt1
  COMMIT TRAN
GO
exec insert_tt1_tt2
GO
SELECT
  *
FROM
  tt1 INNER JOIN tt2 ON tt1.i = tt2.i
GO
DROP PROC insert_tt1_tt2
GO
alter table tt1 DROP constraint FK_tt1_tt2
GO
alter table tt2 DROP constraint FK_tt2_tt1
GO
DROP TABLE tt1
DROP TABLE tt2

Что в принципе может служить подтверждением Ваши слов о "слабости прочих механизмов в конкретном случае". Т.е. о чем я и говорил, использовать в одной СУБД "механизмы" от другой СУБД не совсем корреткно из-за различия в этих механизмах. Но, повторюсь, говорить о "неправильности" реализации этих механизмов, IMHO, некореектно.

Более того, цель, которую я ставлю перед собой при использовании хп - отсутствие в клиентском коде инструкци DML и DDL. Увы и ах, "правильность" реализации механизма "INSTEAD OF (BEFORE) + VIEW" в других СУБД не приводит меня к достижению этой цели, ибо инструкции DML для вьюх (c логикой в триггерах) долны быть именно на клиенте. Если же использовать хп для модификации "INSTEAD OF (BEFORE) + VIEW" - то я не вижу причины, почему бы все не реализовать в хп, включая логику, а не размазывать это на вьюхи, триггера и хп.

softwarer
Хм. То есть предлагаете расслабиться и получать удовольствие?


Совершенно верно. Предлагаю каджому получать "удовольстивие" от той СУБД, с которой каждый работает. ;)
5 июл 06, 11:02    [2843968]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
softwarer
состоял из нескольких десятков тысяч .c-файлов, в каждом из которых было по одной функции.

:) Попытался представить, но не получилось.
5 июл 06, 11:04    [2843982]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
автор
Опять - 25! Используйте, но выполняйте требования СУБД с которой работаете. Да, нельзя в MS SQL в представление с триггером INSTEAD OF не передавать ничего в поле, которое в базовой таблице NOT NULL:


А какой смысл в таких триггерах ? Вы предлагаете решать задачу другими средствами, но есть ли какая-то задача, которую удобно решать этим средством ?


Вы не поверите, что кроме описанного в этом топике (и его прородителе) частного случая "INSTEAD OF INSERT на VIEW над таблицей с полем NOT NULL значение которого заполняется в этом самом INSTEAD OF INSERT" есть и другие случаи, примеры которых уже приводил softwarer, а именно INSTEAD OF DELETE на таблицу, для реализации простановки признака "удаленной записи" и многое другое. :)
5 июл 06, 11:16    [2844069]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ChA wrote:
> locky
> Барин умный - ему виднее... хорошая позиция...
>
> Безусловно, очень конструктивное замечание. Дальше что ? Заставить
> Microsoft сделать системные таблицы, как мы хотим ? Да они вообще могли
> закрыть эту информацию, а дать только процедуры для получения текстов.
ВОТ И ДАЙТЕ МНЕ ПРОЦЕДУРУ ПОЛУЧЕНИЯ ТЕКСТА!!!
Нету? Я так и думал... И не надо мне рассказывать про sp_helptext...
ага.. который не учитывает, что длина поля текст уже поменялась, а сам
текст процедуры не менялся с 6.5... и на некоторых (не всех, согласен)
процедурах текст получается неправильный...
особенно если вспомнить, как именно тулзы МС оный текст получают..
прямой выборкой из syscomments....
а лопатой (равно и экскаватором) - в их МС эквиваленте - я таки умею
работать. И все траблы решаю. Просто - немножно неаккуратно, что я
должен делать ручками то, что по идее должен был получить за денежки,
заплаченные за СКЛ. Хотя - задачи решаю, а каким способом - дело десятое.

> locky
> У меня в рабочей базе 584 процы длинее 8000 байт из 17279 штук
>
> 584*100/17279 ~ 3.38%. Статистика, однако...
Батенька! (простите мою фамильярность!) Как показывает практика, процент
глючных проц - еще меньше! И вот когда один маааленький процент
пересекается с другим... вот это и начинает волновать...
скриптуем всё в файл... ищем в нём фаром...
а то, что скриптование через SQL-DMO базы происходит 2 часа - ничо, не
напрягает? Подождём, твою маму? И почему моя самописка то-же самое
делает за 72 секунды?

> locky
> а утиль, кстати - не очень, надо сказать...
>
> Не с чем спорить, нет идеального средства для каждого. Не нравится - нет
> вопросов, ищите и покупайте. Вы бы в Informix версии 7.3х поработали...
Я УЖЕ купил сервер с набором тулзов.. И, оказывается, я должен заплатить
ЕЩЕ денег, чтобы с оным сервером работать? В сад! или пусть вернут
деньги за EM и QA.
И! А вот не работаю я с информиксом, я с МС СКЛ работаю :-) Нафига мне
знать, что кому-то хуже, чем мне. Меня Я, любимый, волную.


--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

5 июл 06, 11:40    [2844214]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
iscrafm
Попытался представить, но не получилось.

Ну так я как раз о том, что незачем объявлять такой дизайн целью проектирования.

Есть естественная мысль разработчиков всех времен - группировка логически связанных атомов, фрагментов программы, в некие удобные в обращении контейнеры. Эволюция реализаций этой идеи в значительной степени определяет эволюцию ЯП вообще - полагаю, достаточно упомянуть, что "объект" есть один из видов такого контейнера.

В СУБД средства такой контейнеризации, мягко скажем, небогаты. Если говорить об общесуществующих возможностях - практически только две: префиксы в именах и распихивание по схемам/БД. И когда на этом фоне появляется нормальное решение, aka пакеты - скажу так, я совершенно не уверен, что в моем текущем проекте будет хоть одна "просто хранимка", вне пакета. Потому как неудобно.
5 июл 06, 11:48    [2844255]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11574
ChA
hvlad
А для обновления тех view, которые не updatable, предназначены триггеры.
Упс. Это Вы так решили ? Или некоторые из производителей СУБД так решили ? Смотрим
SO/IEC 9075-2:1999 (E)
11.38 <trigger definition>
Function
Define triggered SQL-statements.
Format
<trigger definition> ::=
CREATE TRIGGER <trigger name>
<trigger action time> <trigger event>
ON <table name>
[ REFERENCING <old or new values alias list> ]
<triggered action>
<table name> вижу <view name> - нет. Так что поздравляю Вас с новым открытием.

В вашей копии стандарта от 1999 года просто нет триггеров на view. Как и в моей от 2002 (ISO/IEC 9075-2:200x(E)). И что ?
Ещё раз - при чём тут updatable \ non updatable к нашему вопросу ?
И как Вы собираетесь обновлять non updatable view без триггеров ?

ChA
hvlad
Так вот, ещё раз повторяю, в MSSQL2K невозможно вставить в колонку view, базирующуюся на NOT NULL поле, NULL-значение. И это есть баг. Так как ограничение NOT NULL должно проверяться при попытке вставки в базовую таблицу, а не во view. И, кстати, updatable тут совершенно не причём - это может быть простой селект из одной таблицы.

Привести пример или сами сможете ? :-)
Это было бы багом, если бы такое поведение где-нибудь гарантировалось.
А что - где-то не гарантируется ? Кроме MSSQL :)
Весьма странно проверять ограничения до срабатывания триггеров before, которые могут менять значения полей до вставки в таблицу, не так ли ?

ChA
А теперь, внимание, пример
CREATE TABLE t (id int NOT NULL primary key, i int NOT NULL)
GO
CREATE VIEW v WITH VIEW_METADATA AS SELECT id, CAST(i AS int) AS i FROM t
GO
CREATE TRIGGER vii ON v INSTEAD OF INSERT
AS INSERT INTO t (id, i) SELECT id, 1 FROM inserted
GO

INSERT INTO v (id) VALUES (1)
SELECT * FROM t
SELECT * FROM v
GO
DROP TABLE t
DROP VIEW v
Надеюсь, это было познавательно.
Абсолютно не в тему.

А вот то, что я имел в виду:

use tempdb 
go

create table t (id int not null)
go

create view v_t as
  select id from t
go

insert into v_t values (null)
go

create trigger trg_t_ii on t
 instead of insert
as
  print "trigger trg_t_ii"

  insert into t
  select isnull(id, 0) from inserted
go

insert into t values (null)
insert into v_t values (null)
go

drop trigger trg_t_ii 
go

create trigger trg_v_t_ii on v_t
 instead of insert
as
  print "trigger trg_v_t_ii"

  insert into t
  select isnull(id, 0) from inserted
go

insert into v_t values (null)
go

drop view v_t;
drop table t;
И вот печальные результаты

Server: Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'id', table 'tempdb.dbo.t'; column does not allow nulls. INSERT fails.
The statement has been terminated.

Server: Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'id', table 'tempdb.dbo.t'; column does not allow nulls. INSERT fails.
The statement has been terminated.

Server: Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'id', table 'tempdb.dbo.t'; column does not allow nulls. INSERT fails.
The statement has been terminated.

Server: Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'id', table 'tempdb.dbo.v_t'; column does not allow nulls. INSERT fails.
The statement has been terminated.
Как видите - триггер должен вставить not-null значение в таблицу, но его никто не удосужился вызвать. Ай-яй-яй...

А вот что написано в BOL на эту тему
CREATE TRIGGER
INSTEAD OF

Specifies that the trigger is executed instead of the triggering SQL statement, thus overriding the actions of the triggering statements.
Если бы так и было, то проверка NOT NULL у поля выполнялась бы только при прямом инсерте в таблицу. И, по уму, только после срабатывания INSTEAD OF триггеров. Потому что before-триггеры предназначены для проверки и корректировки вставляемых значений. Если для Вас это не очевидно, то нам не о чем долее говорить

ChA
hvlad
Как раз почему это именно так, боюсь, Вы не знаете
Не бойтесь, не знаю, только предполагаю. Но если Вы знаете больше, то почему бы не поделиться сакральными знаниями ?
Боюсь, за мои предположения, Вы меня или съедите, или заработаете себе язву

ChA
hvlad
Вы неправильно трактуете понятие updatable. Почитайте далее в стандарте как и для чего оно используется.
Неужели ? Аааа, догадался, наверное потому, что в стандарте нет триггеров на view ? И не надо поминать всуе стандарт 2002 года, мы пока говорим, если правильно понимаю, о MSSQL 2000. В таком случае можно говорить только о стандартах 1999 года, да и то с натяжкой. И кстати, откуда у Вас стандарт 2002 ? Мне, и не только мне, о нем неизвестно.
Ну, раз Вам ! не известно, то наверное его не существует
WG3:DRS-013
H2-2002-358
August, 2002
...
Title: (ISO-ANSI Working Draft) Foundation (SQL/Foundation)
Author: Jim Melton (Editor)
...
ISO/IEC JTC 1/SC 32
Date: 2002-08-09
ISO/IEC 9075-2:200x(E)
Что имею, то и читаю

ChA
hvlad
Вы можете дать гарантию, что строки в syscomments нарезаны по границам слов ? Даже если это и так, то фразу из уже двух слов подряд я там могу не найти. Иногда, знаете ли, хочется найти процедурку в сотне-другой по некоторому критерию.
Например syscomments.text like '%insert into mytable%'.
Интересно, почему такую гарантию должен давать я ? Я не дам, и почти уверен, что разрезаны они могут быть как угодно, в том числе и посередине. Никак не могу понять, Вы залезли к кому-то в шкаф и возмущаетесь, что там книги не по алфавиту расставлены ?
Я залез к себе в шкаф и хочу там что-то найти. Кривая организация шкафа не позволяет мне это сделать.
sysdepends отслеживает зависимости не корректно и там нет тех деталей, которые мне нужны.

ChA
Это внутренняя кухня MSSQL, которая не предполагала, что Вы захотите туда залезть со своими запросами, ну если уж залезли, то нечего пенять. Кстати, а Вы не пробовали в SQL Query Analyzer нажать F4 ? Думаю в большинстве случаев этого было бы вполне достаточно.
Поздравляю. Вам достаточно плоского списка объектов. Найдите там все insert'ы в данную таблицу, и живите счастливо

ChA
hvlad
Я работаю с MSSQL с 98 года, начинал ещё с 6.5, так что я знаю о чём говорю.
Глубину опыта уже оценил.
Опять наезд. Я пока воздержусь от комментариев

ChA
hvlad
Просто я так выражаюсь :)
Ну да, да, это, конечно, все объясняет и оправдывает. Во что превратится этот форум, если все начнут "просто выражаться", не задумывались ? Думаю, даже форум ПТ, в сравнении, выглядел бы как степенная беседа джентельменов. Давайте будем все-таки пытаться сдерживать себя...
См выше :)

PS И этот человек предлагал мне не входить в раж ?
5 июл 06, 11:53    [2844284]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
locky
а то, что скриптование через SQL-DMO базы происходит 2 часа - ничо, не
напрягает? Подождём, твою маму? И почему моя самописка то-же самое
делает за 72 секунды?


Не пробовали пользоваться утилитой scptxfr.exe из каталога C:\Program Files\Microsoft SQL Server\MSSQL\Upgrade? ;)
5 июл 06, 11:58    [2844316]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11574
pkarklin
hvlad
Нет не улавливаю. Вот если бы в реализации C++ от Борланд не было мн.насл., то я бы тоже объявил это багом.


Понимаете, баг называют багом не по вашему желанию, а только в том случаи, если поведение какой-либо системы отличается от документированного.

hvlad
Это баг. Я не могу использовать VIEW + INSTEAD OF триггер по назначению - скрыть логику от конечного приложения.


Опять - 25! Используйте, но выполняйте требования СУБД с которой работаете. Да, нельзя в MS SQL в представление с триггером INSTEAD OF не передавать ничего в поле, которое в базовой таблице NOT NULL:

BOL
Columns in the view select list can be nullable or not nullable. If a view column does not allow nulls, an INSERT statement must provide values for the column.
Это всё-таки бага. Если в моём примере выше заменить одно ограничение поля (NOT NULL) на другое (CHECK), то триггеры чудесным образом начинают срабатывать :) Т.е. налицо разная обработка одинаковых, по сути, объектов - ограничений уровня поля.
Да, в MSSQL реализация NOT NULL и CHECK (IS NOT NULL) разная, но это не повод так себя вести

pkarklin
Вариантов "обхода" - море, например, заведение DEFAULT CONSTRAINT и использования клаузы DEFAULT в инструкции INSERT.

Более того, для того, чтобы "скрыть логику от конечного приложения" использование "VIEW + INSTEAD OF" не единственное верное решение. (Об этом чуть позже).
Иногда это практически не возможно, особенно если много связей с базовой таблицей

pkarklin
hvlad
Читаю, просто читаю. Низзя ?


Есть другие способы "читания" текстов хп, триггеров и функций, отличных от прямого доступа к системным таблицам с их якобы "кривизной".
И что - они позволят мне искать фразу, не вытягивая на клиента весь текст ?

pkarklin
hvlad
Из-за убогости поставляемого клиентского утиля, я, вплоть до MSSQL2K, пользовался редактором кода Дельфи для написания процедур. В MSSQL2K хоть синтаксис подсвечивается в Query Analyzer'е :)


У меня возникает подозрение, что Вы не пользовались "клиентским утилем" версий до 2К, ибо подсветка синтаксиса была и там.
Да, 7-ку мы проскочили. Подсветка синтаксиса - единственная радость в новых QA. В остальном - такое же убожество, как и раньше :) Ср-в анализа исходников (хотя бы поиска объектов) как не было, так и нет. А того, кто придумал редактировать процедуры в маленьком модальном окошке EM, я ваще пристрелил бы. Впрочем, это уже не относится к теме.
5 июл 06, 12:15    [2844410]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
iscrafm

Лучше подходить с другого конца. Раскладывать логику на тривиальные процедуры. В этом и есть задача проектирования. Иначе никаких фич субд может не хватить.


Кролики - не только ценный мех
А пакеты далеко не только средство складывания всех процедур в одно место

Да и дисциплинируют пакеты больше чем помойка из отдельныз процедур
5 июл 06, 12:20    [2844451]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Это ожидаемое поведение! И называть такое поведение ошибкой, даже если оно отличается от поведения аналогичного механизма в другой СУБД, IMHO, не совсем корректно.


Это был хороший зонтик, просто он воды боялся.
Синдром шоколадного чайника, в Oracle тоже встречаются такие фичи (и через некоторое время объявляются устаревшими) инкрементальный экспорт к примеру.
Смысл INSTEAD OF именно в определении поведения при добавлении во view (в том числе и автоматическое заполнение NOT NULL полей если потребуется). На другие СУБД смотреть не обязательно (хотя откуда собсна слизали аналитику, версионность и т.п. ?), но со злравым смыслом (пользователя) дружить необходимо.
5 июл 06, 12:25    [2844483]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
2 Cha:

Для меня познавательно что работает с CAST(i AS int), однако ДОЛЖНО работать и без.
5 июл 06, 12:41    [2844593]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
pkarklin
Не спорю. Но это не называют "багом" Delphi или "неправильным" поведением.

Насколько я помню ход дискуссии, слова типа "баг" пошли уже после того, как беседа перешла в довольно напряженное русло. Изначально была сказана вполне разумная (имхо) мысль: есть некое неудобство, и выдвинутая категорическая точка зрения "так и надо" не совсем убедительна.

pkarklin
Это AS IS или by design и с эитм приходится работать.

Приходится. Но если не ошибаюсь, это форум "сравнение СУБД", тема тоже подходящая, и в связи с этим "приходится" вовсе не обязано доставлять радость.

pkarklin
На счет "абсолютно" - согласен, собеседник объявил его просто "неправильным", приведя реализацию такого подхода в "правильной СУБД".

Хм. Реализацию подхода привел я, причем не говоря слов типа правильно-неправильно, и исключительно в ответ на настойчивую просьбу показать, как это можно сделать иначе.

pkarklin
На счет ценности механизма. Совершенно не согласен с Вами, что "наследование" метаданных базовых таблиц является "существенным" снижением ценности механизма updateable view.

Хм. Возможно, я не совсем понял приведенный способ обхода, но я так понял, что он требует изменения дизайна базовой таблицы. Что не слишком хорошо с точки зрения общих концепций.

pkarklin
softwarer
И? by design - это аргумент из серии "это не ошибка, это системная функция".

Это ожидаемое поведение! .....

Я в данном случае говорю исключительно о том, что аргумент сам по себе неубедителен в рамках подобной тематики. Нисколько не характеризуя истинность либо ложность защищаемой им точки зрения, корректность участников итп.

И называть такое поведение ошибкой, даже если оно отличается от поведения аналогичного механизма в другой СУБД, IMHO, не совсем корректно.

pkarklin
softwarer
скажем, мне было бы любопытно посмотреть на не использующее этого подхода нормальное решение следующей простой задачи:


Странно, однако, требовать от СУБД, не имеющих BEFORE триггеров аналогичности в поведении.

Этот абзац хорошо показывает, почему я употребил термин "вскипели".

Если Вы внимательно прочитаете цитату - сказанное мной - я нигде не "требую", нигде - "аналогичности в поведении", и тем более не прошу показать что-то конкретно на MSSQL. Однако, прочитав мои слова, Вы трактуете их.. весьма жестко, что с моей точки зрения вкупе с другими факторами объясняется тем, что Вы несколько "на взводе".

Поясню еще раз: я показал класс задач, для решения которых удобно именно такое взаимодействие триггеров и ограничений (внимание: этот класс шире, нежели связь один к одному; показан всего лишь пример). Я мало верю в возможность хорошего решения этого класса задач другим способом. Соответственно, отсутствие такого инструмента - вынудит искать не очень хорошие решения.

pkarklin
Более того, цель, которую я ставлю перед собой при использовании хп - отсутствие в клиентском коде инструкци DML и DDL.

Хм. Полагаю, если Вы ставите цель, она чем-то обусловлена. Существует два возможных класса причин:

1. Это дает какие-то объективные преимущества.
2. Объективных преимуществ нет, просто нравится, хочется итп.

Я упомянул как раз то, что в конкретном случае MSSQL, рассматриваемый случай является еще одним объективным преимуществом. Что, собственно, является еще одним фактом в пользу моей теории о том, что фразу "все надо делать на процедурах" надо дополнять утверждением "в случае MSSQL".

pkarklin
то я не вижу причины, почему бы все не реализовать в хп, включая логику, а не размазывать это на вьюхи, триггера и хп.

По той же причине, по которой большинство людей в зависимости от ситуации пользуются самолетами, метро, лифтами и велосипедами, не пытаясь ограничиться эксплуатацией автомобиля.
5 июл 06, 12:46    [2844625]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

pkarklin wrote:
> locky
> а то, что скриптование через SQL-DMO базы происходит 2 часа - ничо, не
> напрягает? Подождём, твою маму? И почему моя самописка то-же самое
> делает за 72 секунды?
>
> Не пробовали пользоваться утилитой scptxfr.exe из каталога C:\Program
> Files\Microsoft SQL Server\MSSQL\Upgrade? ;)
Пробовал :-( Медленно... за 26 минут скрипт таки не получен - дольше
ждать религия не позволила :-) Да и входит тулза не комплект клиентских,
а токмо на серваке - неудобно...
а самопалом ~ 2 минуты (включая дамп настроечных справочников - их таки
порядочно :-( )
так-шта.... всё-таки чо-то в МС недодумали....

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

5 июл 06, 12:55    [2844671]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Хм. Реализацию подхода привел я, причем не говоря слов типа правильно-неправильно, и исключительно в ответ на настойчивую просьбу показать, как это можно сделать иначе.


Эээ... А я и отвечал не на Вашу реализацию подхода, а на следующее высказывание:

hvlad
Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое.


softwarer
Хм. Возможно, я не совсем понял приведенный способ обхода, но я так понял, что он требует изменения дизайна базовой таблицы. Что не слишком хорошо с точки зрения общих концепций.


Всего-навсего временной отключение проверки ограничений.

softwarer
Если Вы внимательно прочитаете цитату - сказанное мной - я нигде не "требую", нигде - "аналогичности в поведении", и тем более не прошу показать что-то конкретно на MSSQL. Однако, прочитав мои слова, Вы трактуете их.. весьма жестко, что с моей точки зрения вкупе с другими факторами объясняется тем, что Вы несколько "на взводе".



Ок. Вы не требуете. Согласен. НА счет не просите, гм... как тогда прикажете трактовать следующее:

softwarer
скажем, мне было бы любопытно посмотреть на не использующее этого подхода нормальное решение следующей простой задачи


:) Интересно, если бы я привел скрипт на T-SQL и в диалоге с Вами сказал, что мне было бы "любопытно посмотреть..." Вы бы удержались от приведения кода для Oracle? Так что никакой жесткости в трактовании Ваших слов у меня даже и в мыслях не было. ;)

softwarer
Поясню еще раз: я показал класс задач, для решения которых удобно именно такое взаимодействие триггеров и ограничений (внимание: этот класс шире, нежели связь один к одному; показан всего лишь пример). Я мало верю в возможность хорошего решения этого класса задач другим способом. Соответственно, отсутствие такого инструмента - вынудит искать не очень хорошие решения.


Согласен.

softwarer
Хм. Полагаю, если Вы ставите цель, она чем-то обусловлена. Существует два возможных класса причин:

1. Это дает какие-то объективные преимущества.
2. Объективных преимуществ нет, просто нравится, хочется итп.


Для меня она обусловлена п.1. А о преимуществах (видимых мною) отсутствия в клиентском приложении DML и DLL я уже неоднократно писАл.

softwarer
Я упомянул как раз то, что в конкретном случае MSSQL, рассматриваемый случай является еще одним объективным преимуществом. Что, собственно, является еще одним фактом в пользу моей теории о том, что фразу "все надо делать на процедурах" надо дополнять утверждением "в случае MSSQL".


Думаю не стоит возвращаться еще раз к обсуждению +\- "все надо делать на процедурах". Копий было сломано немало и у каждого все равно останеться своя теория. :)
5 июл 06, 13:16    [2844775]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
pkarklin
Эээ... А я и отвечал не на Вашу реализацию подхода, а на следующее высказывание:

И как Вы можете заметить, в нем не говорится ни о "багах", ни о "правильных/неправильных"... О чем я и говорю - Вы воспринимаете сказанное существенно измененным по сравнению с оригиналом.

pkarklin
softwarer
Хм. Возможно, я не совсем понял приведенный способ обхода, но я так понял, что он требует изменения дизайна базовой таблицы. Что не слишком хорошо с точки зрения общих концепций.


Всего-навсего временной отключение проверки ограничений.

Отключали Вы в том фрагменте кода, который привели мне. Если я правильно помню, в MSSQL DDL-операции не вызывают коммита и следовательно отключение будет в пределах сессии, так что способ в целом приемлимый.

Я же, однако, говорил о способе обхода проблемы со вставкой во view. Не очень четко помню тот фрагмент, но там вроде бы говорилось о замене NOT NULL на другой тип constraint-а.

pkarklin
softwarer
и тем более не прошу показать что-то конкретно на MSSQL.

Ок. Вы не требуете. Согласен. НА счет не просите, гм... как тогда прикажете трактовать следующее:

softwarer
скажем, мне было бы любопытно посмотреть на не использующее этого подхода нормальное решение следующей простой задачи


:) Интересно, если бы я привел скрипт на T-SQL и в диалоге с Вами сказал, что мне было бы "любопытно посмотреть..." Вы бы удержались от приведения кода для Oracle?

OK, прежде всего отвечаю на вопрос "как трактовать". Как констатацию того факта, что я сомневаюсь в существовании хорошего решения, не использующего этого подхода, был бы несколько удивлен и несколько обрадован, если бы такое увидел, однако не хочу прямо утверждать "нельзя".

Далее, насчет удержался и жесткости. Прямой и тупой ответ - "зависит от ситуации". Например, в какой-то ситуации я бы ответил, что не попадал в такие ситуации, не могу сконструировать примера, в котором этот подход будет хорошим решением и соответственно не вижу смысла обдумывать решение такой задачи. Интересно, однако, другое.

Интересно то, что в контексте, в котором я максимально убрал противопоставление конкретных БД, оставив сугубо абстрактную задачу в рамках подходов, Вы, судя по формулировке ответа, таки углядели священную войну Oracle - MSSQL. Признаться, не очень понимаю - неужели мне требовалось написать этот пример, скажем, на Interbase, чтобы таки быть понятым буквально? Или все равно не помогло бы?

pkarklin
Так что никакой жесткости в трактовании Ваших слов у меня даже и в мыслях не было. ;)

Хм. Вот как раз в этом я нискольку не сомневаюсь :)
5 июл 06, 15:39    [2845733]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
hvlad
И как Вы собираетесь обновлять non updatable view без триггеров ?
Как правило, не испытываю в этом нужды. В случае острой необходимости, воспользуюсь INSTEAD-триггером.
hvlad
А что - где-то не гарантируется ? Кроме MSSQL :)
Весьма странно проверять ограничения до срабатывания триггеров before, которые могут менять значения полей до вставки в таблицу, не так ли ?
"Если бы у бабушки были ...", дальше, уверен, сами знаете.
hvlad
А вот то, что я имел в виду:
Да, понятно, что Вы имели в виду, приведенный мною пример как раз и давал желаемое поведение, но он оказался
hvlad
Абсолютно не в тему.
Был более чем уверен, что ответ последует именно в таком духе.
hvlad
Если бы так и было, то проверка NOT NULL у поля выполнялась бы только при прямом инсерте в таблицу. И, по уму, только после срабатывания INSTEAD OF триггеров. Потому что before-триггеры предназначены для проверки и корректировки вставляемых значений. Если для Вас это не очевидно, то нам не о чем долее говорить
INSTEAD-триггер != BEFORE-триггер. Вторых у MSSQL просто не существует, соответственно, ждать от INSTEAD такого же поведение, как от BEFORE, несколько самонадеянно. Ваше право считать "багом", что MSSQL делает "неправомерную" проверку на допустимость NULL-значений до "реальной" модификации данных, мое право - не согласиться.
hvlad
WG3:DRS-013
H2-2002-358
August, 2002
...
Title: (ISO-ANSI Working Draft) Foundation (SQL/Foundation)
Author: Jim Melton (Editor)
...
ISO/IEC JTC 1/SC 32
Date: 2002-08-09
ISO/IEC 9075-2:200x(E)
ОК, вопрос закрыт, Working Draft.
hvlad
Я залез к себе в шкаф и хочу там что-то найти. Кривая организация шкафа не позволяет мне это сделать.
sysdepends отслеживает зависимости не корректно и там нет тех деталей, которые мне нужны.
Пользуйтесь только "правильными" шкафами. Честное слово, не понимаю, зачем Вы себя так мучаете, с 1998 года, ведь есть же другие, более "правильные" СУБД.

locky
ВОТ И ДАЙТЕ МНЕ ПРОЦЕДУРУ ПОЛУЧЕНИЯ ТЕКСТА!!!
:) В Microsoft обращаться не пробовали ? Вы полагаете, что в других СУБД все отлично и нет ни одного повода для претензий ? Вы, правда, думаете, что если выскажете свое недовольство здесь, да еще и, почему-то, мне, то что-то изменится ?
locky
И почему моя самописка то-же самое
делает за 72 секунды?
Замечательно, пользуйтесь ей ;) Можете попробовать продать.
locky
Я УЖЕ купил сервер с набором тулзов.. И, оказывается, я должен заплатить
ЕЩЕ денег, чтобы с оным сервером работать? В сад! или пусть вернут
деньги за EM и QA.
Неа, Вы хотите большего, чем Вам предлагают ;) Как Вы думаете, какая % имеют EM и QA в общей стоимости ? Что-то мне подсказывает, что Вы немного таким образом сэкономите. А с другой стороны, почему бы и нет ? Подаете в суд на MS, выигрываете дело, и Вы миллионер...
5 июл 06, 15:47    [2845798]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Я же, однако, говорил о способе обхода проблемы со вставкой во view. Не очень четко помню тот фрагмент, но там вроде бы говорилось о замене NOT NULL на другой тип constraint-а.


Да, на CHECK. Вот пример кода:

USE pubs
GO
CREATE TABLE Table1(col1 int NULL CHECK (col1 IS NOT NULL), col2 char(1) NOT NULL)
GO
CREATE VIEW View1
AS
  SELECT col1, col2 FROM Table1
GO

CREATE TRIGGER it_Table1 ON View1
INSTEAD OF INSERT
AS
  INSERT Table1
  SELECT ISNULL(col1, 0), col2 FROM inserted
GO
INSERT INTO Table1 VALUES(NULL, 'A')
GO
INSERT INTO View1(col2) VALUES('A')
INSERT INTO View1(col2) VALUES('B')
INSERT INTO View1(col2) VALUES('C')

INSERT INTO View1 VALUES(NULL, 'D')
INSERT INTO View1 VALUES(NULL, 'E')
INSERT INTO View1 VALUES(NULL, 'F')
GO

SELECT * FROM Table1
GO
DROP VIEW View1
DROP Table Table1

Server: Msg 547, Level 16, State 1, Line 1
INSERT statement conflicted with COLUMN CHECK constraint 'CK__Table1__col1__26509D48'.
The conflict occurred in database 'pubs', table 'Table1', column 'col1'.
The statement has been terminated.

col1        col2 
----------- ---- 
0           A
0           B
0           C
0           D
0           E
0           F


softwarer
Интересно то, что в контексте, в котором я максимально убрал противопоставление конкретных БД, оставив сугубо абстрактную задачу в рамках подходов, Вы, судя по формулировке ответа, таки углядели священную войну Oracle - MSSQL. Признаться, не очень понимаю - неужели мне требовалось написать этот пример, скажем, на Interbase, чтобы таки быть понятым буквально? Или все равно не помогло бы?


Зря Вы пытаетесь найти в моих высказываниях "священную войну". :( Я ее никогда не вел и вести не собираюсь. Я никогда не высказывался о какой-либо другой СУБД, противопоставляя ей MS SQL в стиле "а вот в нормальных СУБД...", тем самым указывая на ее ненормальность.
5 июл 06, 16:23    [2846118]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11574
ChA
Ваше право считать "багом", что MSSQL делает "неправомерную" проверку на допустимость NULL-значений до "реальной" модификации данных, мое право - не согласиться
Мне дали право ! Ура ! Спасибо !
На этом пожалуй и закончим, утомили Вы меня пустыми разговорами...

ChA
ОК, вопрос закрыт, Working Draft
Да, да - со специально внесёнными неточностями, дабы было что исправлять к 2003-му году Смешно, право

ChA
Пользуйтесь только "правильными" шкафами. Честное слово, не понимаю, зачем Вы себя так мучаете, с 1998 года, ведь есть же другие, более "правильные" СУБД
Дык - пользуюсь, верите ? :) Просто есть такое понятие - работа. И определяется она не только хочу\не хочу, MS\не MS, но и другими хар-ками, как ни странно. И не нужно давать мне рекомендаций о том кем и с чем раболтать - я уж как-нибудь разберусь. А насчёт мучений - в MSSQL есть гораздо более серьёзные, скажем мягко, странности, но они есть везде.

И накидываться на всякого, кто указывает на эти недостатки (и баги :), с пеной у рта всё отрицая, как будто бы от этого зависит Ваш оклад, мягко говоря, не умно.
5 июл 06, 18:33    [2847036]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
hvlad
Поздравляю, безусловная победа эмоций над разумом.
5 июл 06, 19:09    [2847161]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить