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

Откуда:
Сообщений: 11555
Мне, наверное, везёт на закрытые темы :)
Тем не менее, не разжигая флейма, хотелось бы всё-таки ответить :

ChA
hvlad
Ограничения на таблицах ? Вот пусть таблицы его и проверяют
Все на самом деле несколько иначе. При обновления данных через view существуют определенные ограничения, которые, во-первых, описаны явно в документации, во-вторых, ограничения для подобных view есть в описании стандарта ANSI, хотя не готов ставить между ними полного равенства
Хотелось бы ссылку на стандарт.

ChA
Факт то, что они существуют, ведь, надеюсь, понятно, что не всякое view можно обновить ?
Причём тут это ?

ChA
Ровно исходя из этого и берется определенная информация об ограничениях прямо из базовых таблиц, кажется это правильным или нет.
Есть триггера INSTEAD или нет - дело последнее, их наличие не меняет ситуации, это просто механизм, который срабатывает при определенных условиях, не более того. Соответственно, поведение updatable views не меняется от того, добавили потом триггера или нет
Не нужно притягивать за уши поведение конкретного сервера и объявлять его единственно правильным.
Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое. В MSSQL2K такой триггер (INSTEAD OF INSERT конечно) просто не вызывается

ChA
hvlad
Да, да - "дизайн" syscomments - верх совершенства, давайте пихать его во все дыры
Не надо передергивать, вопрос сколько урлов должно быть в записи, целиком и полностью зависит от проектирования. Плохо, когда ограничения СУБД мешают ему, но, допустим, проектировщик добавляет поля url1, ..., urlN в одну запись на все случаи жизни. В этом случае у меня лично возникают некоторые сомнения в адекватности подхода
Не зная постановки задачи, я бы не стал говорить о качестве проектирования. ФИО Вы тоже храните в 3-х записях ?

ChA
А чем syscomments не угодила, совсем непонятно, что Вы там забыли ?
Тексты процедур и триггеров, как ни странно :) А Вы что думали ? Или это очередная священная корова ?

ChA
Это вотчина разработчиков СУБД, и если они применили этот подход, то возможно нашли в нем положительные качества. Или Вы считаете, что безусловно правы ? Тогда нет вопросов, MSSQL делали бараны.
Конечно нет вопросов, особенно глядя на клиентский утиль
4 июл 06, 17:32    [2842187]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
автор
Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое. В MSSQL2K такой триггер (INSTEAD OF INSERT конечно) просто не вызывается


В Delphi нет множественного наследования, а в "нормальном" языке (С++) есть!!!

Не улавливаете аналогии?!

автор
Не нужно притягивать за уши поведение конкретного сервера и объявлять его единственно правильным.


Не надо пытаться с подходами, используемыми при проектировании на одной СУБД "лезть в огород" другой СУБД, и, увидев, что эти подходы неприменимы, объявлять поведение этой другой СУБД абсолютно неправильным. Если я счас полезу с подходами, используемыми мною при работе с MS SQL к Oracle и буду орать, что там это не так и это не эдак и поэтому Oracle неправильная СУБД, то что здесь начнеться?!

Это поведение описано в документации. Т.е. оно by design. Нравиться это Вам или не нравиться, но с этим придеться мириться или отказаться от использования этой "другой СУБД".

Отсутствие множественного наследования в Delphi, тем не менее, ни чуть не мешает создавать на нем "качественные" приложения. Тоже самое касается и "другой СУБД".

автор
Тексты процедур и триггеров, как ни странно :)


И что Вы такое вытворяете с текстами хп и триггеров в своих проектах, что Вам так неугодила syscomments?

автор
Конечно нет вопросов, особенно глядя на клиентский утиль


Когда аргументов нет в "бой идут" понятия. Ну не нравиться Вам клиентский утиль - напишите свой. Функционал СУБД и ее применимость в первую очередь ни этим определяется.
4 июл 06, 17:55    [2842315]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11555
pkarklin
автор
Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое. В MSSQL2K такой триггер (INSTEAD OF INSERT конечно) просто не вызывается


В Delphi нет множественного наследования, а в "нормальном" языке (С++) есть!!!

Не улавливаете аналогии?!
Нет не улавливаю. Вот если бы в реализации C++ от Борланд не было мн.насл., то я бы тоже объявил это багом.

pkarklin
автор
Не нужно притягивать за уши поведение конкретного сервера и объявлять его единственно правильным.


Не надо пытаться с подходами, используемыми при проектировании на одной СУБД "лезть в огород" другой СУБД, и, увидев, что эти подходы неприменимы, объявлять поведение этой другой СУБД абсолютно неправильным. Если я счас полезу с подходами, используемыми мною при работе с MS SQL к Oracle и буду орать, что там это не так и это не эдак и поэтому Oracle неправильная СУБД, то что здесь начнеться?!

Это поведение описано в документации. Т.е. оно by design. Нравиться это Вам или не нравиться, но с этим придеться мириться или отказаться от использования этой "другой СУБД".
Это баг. Я не могу использовать VIEW + INSTEAD OF триггер по назначению - скрыть логику от конечного приложения.

pkarklin
Отсутствие множественного наследования в Delphi, тем не менее, ни чуть не мешает создавать на нем "качественные" приложения. Тоже самое касается и "другой СУБД".
Аналогия неверная.

pkarklin
автор
Тексты процедур и триггеров, как ни странно :)


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

pkarklin
автор
Конечно нет вопросов, особенно глядя на клиентский утиль


Когда аргументов нет в "бой идут" понятия. Ну не нравиться Вам клиентский утиль - напишите свой. Функционал СУБД и ее применимость в первую очередь ни этим определяется.
Та написал, написал :)
Угу, не этим. А возможностями триггеров, в частности
4 июл 06, 18:27    [2842463]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
автор
Не надо пытаться с подходами, используемыми при проектировании на одной СУБД "лезть в огород" другой СУБД, и, увидев, что эти подходы неприменимы, объявлять поведение этой другой СУБД абсолютно неправильным

Разумные выводы. Редко встретишь. Особенно в "Сравнение СУБД" :)
4 июл 06, 18:28    [2842471]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11555
pkarklin
Это поведение описано в документации. Т.е. оно by design. Нравиться это Вам или не нравиться, но с этим придеться мириться или отказаться от использования этой "другой СУБД".
Кстати, не могу найти в BOL MSSQL2K такого описания
4 июл 06, 18:29    [2842474]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, pkarklin!
Ты пишешь:

pkarklin
p> В Delphi нет множественного наследования, а в "нормальном" языке (С++) есть!!!
p> Не улавливаете аналогии?!
С# говно!
В нем нет множественного наследования.
M$ специально делает говно.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

4 июл 06, 18:30    [2842477]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11555
iscrafm
автор
Не надо пытаться с подходами, используемыми при проектировании на одной СУБД "лезть в огород" другой СУБД, и, увидев, что эти подходы неприменимы, объявлять поведение этой другой СУБД абсолютно неправильным

Разумные выводы. Редко встретишь. Особенно в "Сравнение СУБД" :)
Сами по себе - да. Но не в данном случае :)
4 июл 06, 18:30    [2842480]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
pkarklin
В Delphi нет множественного наследования, а в "нормальном" языке (С++) есть!!!

И это один из недостатков Delphi.

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

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

pkarklin
Это поведение описано в документации. Т.е. оно by design.

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

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

SQL> create sequence s1 ;

Sequence created

SQL> create table tt1 (i integer not null primary key) ;

Table created

SQL> create table tt2 (i integer not null primary key) ;

Table created

SQL> alter table tt1 add foreign key (i) references tt2 (i) ;

Table altered

SQL> alter table tt2 add foreign key (i) references tt1 (i) ;

Table altered

SQL> create trigger tt1_bi before insert on tt1 for each row
  2  begin
  3    insert into tt2 values (:new.i) ;
  4  end ;
  5  /

Trigger created

SQL> insert into tt1 select rownum from dual connect by level <= 10 ;

10 rows inserted

SQL> select * from tt1 natural join tt2 ;

                                      I
---------------------------------------
                                      1
                                      2
                                      3
                                      4
                                      5
                                      6
                                      7
                                      8
                                      9
                                     10

10 rows selected

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

pkarklin
Нравиться это Вам или не нравиться, но с этим придеться мириться или отказаться от использования этой "другой СУБД".

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

pkarklin
Отсутствие множественного наследования в Delphi, тем не менее, ни чуть не мешает создавать на нем "качественные" приложения.

Ну, я бы сказал, что это высказывание из серии "зелен виноград".

pkarklin
Тоже самое касается и "другой СУБД".

--//--

pkarklin
Когда аргументов нет в "бой идут" понятия.

Именно.
4 июл 06, 18:31    [2842486]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, softwarer!
Ты пишешь:

softwarer
pkarklin
В Delphi нет множественного наследования, а в "нормальном" языке (С++) есть!!!

s> И это один из недостатков Delphi.
Я вас умоляю, не ешьте на ночь сырых помидоров!
Концепция Multiple Inheritance весьма спорная.
Битвы в ООП-форумах всё ещё бушуют.
Преподносить это, как акуенное достоинство,
либо же акуительный недостаток, право же, не стОит...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

4 июл 06, 18:38    [2842514]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
hvlad
Хотелось бы ссылку на стандарт
.В сети эти стандарты не выставлены, по причине, если правильно помню, что за них надо платить. В то же время отдельными файлами мелькает, если захотите, то найдете. Начните, например, отсюда
ISO/IEC 9075-2:1999 (E)

11.21 <view definition>
Syntax Rule
...
9) The viewed table is updatable if and only if the <query expression> is updatable.
...
И далее по списку, какие <query expression> бывают updatable, но это уж сами как-нибудь. Даже странно, что, по слухам, разработчику некоей СУБД, надо объяснять то, что худо-бедно, но таки описано в стандарте ANSI-SQL. Интересно, как Вы собираетесь обновлять view с OUTER JOIN, например ? Тем более, если в списке полей view некоторые поля из OUTER отсутствуют. А если вместо полей используются выражения ?
hvlad
Причём тут это ?
При том, что в данном случае Вы вырвали фразы из контекста в котором она имела смысл.
hvlad
Не нужно притягивать за уши поведение конкретного сервера и объявлять его единственно правильным.Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое. В MSSQL2K такой триггер (INSTEAD OF INSERT конечно) просто не вызывается
Почему-то мне кажется, что это пытаетесь сделать Вы. Я всего лишь попытался описать, почему так происходит в MSSQL. Если Вы были и его разработчиком, и точно знаете, что все не так, буду только рад услышать больше. Повторюсь, обновляемость view никоим образом не зависит от наличия/отсутствия триггеров, по крайней мере, в стандарте этого не видел, хотя и готов допустить, что был невнимателен. Если вдруг найдете, то буду благодарен, если устраните пробел в моей памяти.
hvlad
Не зная постановки задачи, я бы не стал говорить о качестве проектирования. ФИО Вы тоже храните в 3-х записях ?
Абсолютно с Вами согласен, именно поэтому и был специально приведен пример. Не исключаю, что в зависимости от задачи и ФИО может оказаться в 3-х записях. Но "в лоб" отражать XML в структуру таблицы мне представляется не совсем верным.

hvlad
Тексты процедур и триггеров, как ни странно
Есть другие, вполне документированные способы, их получить. Вы, вероятно, предпочитаете, недокументрованные, но тогда не надо делать больших глаз. Еще раз повторю, если разработчики MSSQL решили использовать такой способ, то вероятно были определенные резоны для такого решения. Мне видится связь с тем, что, статистически, процедур больше 8КБ не так уж много, чтобы непременно использовать для их хранения image/text. Но это всего лишь мое мнение, возможно у них были другие, более веские основания.
hvlad
нет вопросов, особенно глядя на клиентский утиль
Допускаю, что Вы не смогли в нем разобраться, но не уверен, что это безусловная проблема их разработчиков. Мне, например, за много лет никаких средств третьих фирм не понадобилось.

P.S. hvlad, огромная просьба не входить в раж и обходиться без особого полемического задора. Мы либо пытаемся найти общий язык, либо доказать кто находчивее. Мне кажется, что здесь не КВН. Если Вы считате иначе, и стеб считается аргументом, то позвольте откланяться.
4 июл 06, 19:13    [2842627]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, ChA!
Ты пишешь:

ChA
C> Интересно, как Вы собираетесь обновлять view с OUTER JOIN, например ?
C> Тем более, если в списке полей view некоторые поля из OUTER отсутствуют.
C> А если вместо полей используются выражения ?
ПоплакалЪ
Аффтар редкостный специализд!
MsSQL форева!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

4 июл 06, 19:18    [2842637]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gold
Member

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

автор
C> Интересно, как Вы собираетесь обновлять view с OUTER JOIN, например ?
C> Тем более, если в списке полей view некоторые поля из OUTER отсутствуют.
C> А если вместо полей используются выражения ?


С такой логикой таблица с COMPUTED BY полем тоже необновляемая, так?

Триггер INSTEAD OF как раз предназначен для того чтобы выполнить действия вместо операции, производимой над представлением. Это своего рода полиморфизм. Поля у меня есть (неважно как они получены). Что мешает мне перекрыть в триггере INSTEAD OF страндартное поведение команды INSERT и выполнить нужное мне действие?

Конкретно в MSSQL попробуйте создать представление на таблице с IDENTITY NOT NULL и вставить данные в таблицу. Возможно даже INSTEAD OF триггер не понадобиться. Сервер просто обяжет вас задать значение поля IDENTITY, что есть бред, потому как IDENTITY будет заполнено автоматически совсем другим значением.
4 июл 06, 20:34    [2842746]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
locky
Member

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

Возвращаясь к примеру из закрытого топика с Update - таки есть в BOL
описание нового синтаксиса, правда... очень оно хитро закопано

mk:@MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\instsql.chm::/in_backcomp2_4dvd.htm
Compatibility, UPDATE (Level 4)

In Microsoft SQL Server version 6.0, the following UPDATE statement,
using two different table aliases for the same base table, was allowed:
CREATE TABLE t1 (c1 int)
GO
INSERT t1 VALUES (1)
INSERT t1 VALUES (2)
GO
UPDATE t1
SET c1 = 50
FROM t1 a1, t1 a2
WHERE a1.c1 = 1 AND
a2.c1 = 2
GO

MS SQL Server 2000

Syntax no longer supported. Use the alias, rather than the table name,
after the UPDATE keyword. The UPDATE statement would be rewritten to:
UPDATE a1
SET c1 = 50
FROM t1 a1, t1 a2
WHERE a1.c1 = 1 AND
a2.c1 = 2

Expect differences in behavior as compared to SQL Server version 6.0.


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

Posted via ActualForum NNTP Server 1.3

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

Откуда: 127.0.0.1
Сообщений: 67468
Блог
Мимопроходящий
Я вас умоляю, не ешьте на ночь сырых помидоров!

Хм. Кстати, спасибо за идею.

Мимопроходящий
Концепция Multiple Inheritance весьма спорная.
Битвы в ООП-форумах всё ещё бушуют.
Преподносить это, как акуенное достоинство,
либо же акуительный недостаток, право же, не стОит...

Тем более не стоит преподносить столь банальную и не столь однозначную истину.

Как факт, нынешняя дельфа затягивает в себя никак не менее спорные, но однозначно менее полезные концепции. Хорошо бы уж тогда сделать действительно большой шаг вперед.

А насчет "зелен виноград" - увы, примеров выше крыши. Те же яверы долго рассказывали, как не нужны template-ы и до сих пор рассказывают, какая гадкая вещь - переопределение операторов. В спорах вокруг вышеупомянутого сервера ненужность версионности постулировалась до тех пор, пока ее не появилось. С множественным наследованием ситуация более очевидна; в любой большой библиотеке классов, в той же VCL, легко указать места, где отсутствие множественного наследования вынуждает к существенно кривым решениям. Но если VCL неплохо держится за счет довольно "крупноблочных" классов, то JDK, в которой попытались сочетать единонаследие с детально проработанной иерархией... вот уж воистину, не стоит вспоминать об этом перед сном. Навскидку один пример - классы JFrame (это нечто типа TForm) и JInternalFrame (это нечто типа TForm.FormStyle = fsMDIChild) ближайшим общим предком имеют не то JComponent, не то Component (аналог сами догадываетесь чего).
4 июл 06, 21:58    [2842872]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
hvlad
Member

Откуда:
Сообщений: 11555
ChA
hvlad
Хотелось бы ссылку на стандарт
.В сети эти стандарты не выставлены, по причине, если правильно помню, что за них надо платить. В то же время отдельными файлами мелькает, если захотите, то найдете. Начните, например, отсюда
ISO/IEC 9075-2:1999 (E)

11.21 <view definition>
Syntax Rule
...
9) The viewed table is updatable if and only if the <query expression> is updatable.
...
И далее по списку, какие <query expression> бывают updatable, но это уж сами как-нибудь. Даже странно, что, по слухам, разработчику некоей СУБД, надо объяснять то, что худо-бедно, но таки описано в стандарте ANSI-SQL. Интересно, как Вы собираетесь обновлять view с OUTER JOIN, например ? Тем более, если в списке полей view некоторые поля из OUTER отсутствуют. А если вместо полей используются выражения ?
А что такое updatable view по-Вашему ? Мне вот почему-то кажется, что это те view, которые могут быть обновлены сервером самостоятельно ? А для обновления тех view, которые не updatable, предназначены триггеры. Так вот, ещё раз повторяю, в MSSQL2K невозможно вставить в колонку view, базирующуюся на NOT NULL поле, NULL-значение. И это есть баг. Так как ограничение NOT NULL должно проверяться при попытке вставки в базовую таблицу, а не во view. И, кстати, updatable тут совершенно не причём - это может быть простой селект из одной таблицы.

Привести пример или сами сможете ? :-)

Ссылку я просил на указание такого поведения derived колонок view, при котором они обязаны наследовать constraints базовой таблицы.

Насчёт вышеупомянутых слухов - их легко проверить

ChA
hvlad
Причём тут это ?
При том, что в данном случае Вы вырвали фразы из контекста в котором она имела смысл.
Я цитировал и цитирую Вас целиком

ChA
hvlad
Не нужно притягивать за уши поведение конкретного сервера и объявлять его единственно правильным.Есть таблица с NOT NULL полем. Есть VIEW на неё. В MSSQL2K нет способа вставить в это VIEW (не таблицу!) поле NOT NULL. В нормальном сервере, при необходимости, пишется триггер BEFORE INSERT на это VIEW (или таблицу), в котором значение поля меняется на допустимое. В MSSQL2K такой триггер (INSTEAD OF INSERT конечно) просто не вызывается
Почему-то мне кажется, что это пытаетесь сделать Вы. Я всего лишь попытался описать, почему так происходит в MSSQL.
Как раз почему это именно так, боюсь, Вы не знаете

ChA
Если Вы были и его разработчиком, и точно знаете, что все не так, буду только рад услышать больше. Повторюсь, обновляемость view никоим образом не зависит от наличия/отсутствия триггеров, по крайней мере, в стандарте этого не видел, хотя и готов допустить, что был невнимателен. Если вдруг найдете, то буду благодарен, если устраните пробел в моей памяти.
Вы неправильно трактуете понятие updatable. Почитайте далее в стандарте как и для чего оно используется.
В моей копии стандарта SQL 2002 нет понятия INSTEAD OF триггеров, соответственно не сказано как они влияют на обновляемость вьюх. Но, ещё раз подчёркиваю, обновляемость вьюх не имеет отношения к нашему вопросу.

ChA
hvlad
Тексты процедур и триггеров, как ни странно
Есть другие, вполне документированные способы, их получить. Вы, вероятно, предпочитаете, недокументрованные, но тогда не надо делать больших глаз. Еще раз повторю, если разработчики MSSQL решили использовать такой способ, то вероятно были определенные резоны для такого решения.
Это придумали не в MS. Этот способ ими унаследован ещё от Sybase. И, кажется мне, не от хорошей жизни, а от рализации блобов. Но это другой вопрос

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

ChA
hvlad
нет вопросов, особенно глядя на клиентский утиль
Допускаю, что Вы не смогли в нем разобраться, но не уверен, что это безусловная проблема их разработчиков. Мне, например, за много лет никаких средств третьих фирм не понадобилось.
Я работаю с MSSQL с 98 года, начинал ещё с 6.5, так что я знаю о чём говорю.

ChA
P.S. hvlad, огромная просьба не входить в раж и обходиться без особого полемического задора. Мы либо пытаемся найти общий язык, либо доказать кто находчивее. Мне кажется, что здесь не КВН. Если Вы считате иначе, и стеб считается аргументом, то позвольте откланяться.
Ради бога, я никого не принуждаю. Если мои фразы иногда кажутся излишне эмоциональными или даже обидными - я не имею в виду ничего подобного. Просто я так выражаюсь :) Достаточно мне на это указать, и я приму это к сведению.
Я, кстати, не делал заявлений о Вас лично, в отличие от...
4 июл 06, 22:40    [2842940]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
locky
Member

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

ChA wrote:
> больших глаз. Еще раз повторю, если разработчики MSSQL решили
> использовать такой способ, то вероятно были определенные резоны для
> такого решения.
Барин умный - ему виднее... хорошая позиция...

> Мне видится связь с тем, что, статистически, процедур
> больше 8КБ не так уж много, чтобы непременно использовать для их
> хранения image/text. Но это всего лишь мое мнение, возможно у них были
> другие, более веские основания.
У меня в рабочей базе 584 процы длинее 8000 байт из 17279 штук

> hvlad
> нет вопросов, особенно глядя на клиентский утиль
>
> Допускаю, что Вы не смогли в нем разобраться, но не уверен, что это
> безусловная проблема их разработчиков. Мне, например, за много лет
> никаких средств третьих фирм не понадобилось.
а утиль, кстати - не очень, надо сказать...
попробуйте нормально сориентироваться среди такого скопища объектов....
поиск по имени, части имени, организация "букетов" процедур....
в MSVID еще хоть как-то, но он зараза - денег стоит отдельных...
приходится выкручиваться самописками...

и искать по серверным текстам приходится путем получения text из
syscomments на клиента, а уж по нему grep-образным способом...
ибо, как правильно заметил hvlad - текст режется на куски без учета слов
и прочей требухи...

зы на всяк случ (типа - "Тулзы не знаешь, научись!" и всё такое) -
начинал в 1997 году с 6.5 -> 7.0 -> 2000 -> (plan) 2005


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

Posted via ActualForum NNTP Server 1.3

4 июл 06, 23:09    [2842968]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
hvlad
А что такое updatable view по-Вашему ? Мне вот почему-то кажется, что это те view, которые могут быть обновлены сервером самостоятельно ?
Слава Богу, наконец-то.
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> - нет. Так что поздравляю Вас с новым открытием.
hvlad
Так вот, ещё раз повторяю, в MSSQL2K невозможно вставить в колонку view, базирующуюся на NOT NULL поле, NULL-значение. И это есть баг. Так как ограничение NOT NULL должно проверяться при попытке вставки в базовую таблицу, а не во view. И, кстати, updatable тут совершенно не причём - это может быть простой селект из одной таблицы.

Привести пример или сами сможете ? :-)
Это было бы багом, если бы такое поведение где-нибудь гарантировалось. А теперь, внимание, пример
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
Надеюсь, это было познавательно.
hvlad
Насчёт вышеупомянутых слухов - их легко проверить
Не понял, каких слухов ?
hvlad
Я цитировал и цитирую Вас целиком
Угу, я заметил.
hvlad
Как раз почему это именно так, боюсь, Вы не знаете
Не бойтесь, не знаю, только предполагаю. Но если Вы знаете больше, то почему бы не поделиться сакральными знаниями ?

hvlad
Вы неправильно трактуете понятие updatable. Почитайте далее в стандарте как и для чего оно используется.
Неужели ? Аааа, догадался, наверное потому, что в стандарте нет триггеров на view ? И не надо поминать всуе стандарт 2002 года, мы пока говорим, если правильно понимаю, о MSSQL 2000. В таком случае можно говорить только о стандартах 1999 года, да и то с натяжкой. И кстати, откуда у Вас стандарт 2002 ? Мне, и не только мне, о нем неизвестно.
hvlad
Вы можете дать гарантию, что строки в syscomments нарезаны по границам слов ? Даже если это и так, то фразу из уже двух слов подряд я там могу не найти. Иногда, знаете ли, хочется найти процедурку в сотне-другой по некоторому критерию.
Например syscomments.text like '%insert into mytable%'.
Интересно, почему такую гарантию должен давать я ? Я не дам, и почти уверен, что разрезаны они могут быть как угодно, в том числе и посередине. Никак не могу понять, Вы залезли к кому-то в шкаф и возмущаетесь, что там книги не по алфавиту расставлены ? Это внутренняя кухня MSSQL, которая не предполагала, что Вы захотите туда залезть со своими запросами, ну если уж залезли, то нечего пенять. Кстати, а Вы не пробовали в SQL Query Analyzer нажать F4 ? Думаю в большинстве случаев этого было бы вполне достаточно.
hvlad
Я работаю с MSSQL с 98 года, начинал ещё с 6.5, так что я знаю о чём говорю.
Глубину опыта уже оценил.
hvlad
Просто я так выражаюсь :)
Ну да, да, это, конечно, все объясняет и оправдывает. Во что превратится этот форум, если все начнут "просто выражаться", не задумывались ? Думаю, даже форум ПТ, в сравнении, выглядел бы как степенная беседа джентельменов. Давайте будем все-таки пытаться сдерживать себя...
5 июл 06, 00:10    [2843030]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
c127
Guest
iscrafm
автор
Не надо пытаться с подходами, используемыми при проектировании на одной СУБД "лезть в огород" другой СУБД, и, увидев, что эти подходы неприменимы, объявлять поведение этой другой СУБД абсолютно неправильным

Разумные выводы. Редко встретишь. Особенно в "Сравнение СУБД" :)


Глупость ИМХО, как первое так и второе. Не бывает подходов, применимых в одной РСУБД и неприменимых в другой, тогда это не РСУБД вообще. Подходы должны работать везде в РСУБД, а вот техника может отличаться.

Это тенденция. Вот например еще заморочка появилась в последнее время, типа версионник и блокировочник, они разные, для них нужно все проектировать по-другому и вообще даже сравнивать нельзя. Блин, бред. РСУБД она и в африке РСУБД, для того и придумана теория, чтобы проектировать БД этого класса одинаково. Согласно теории транзакции должны быть и обладать заданными свойствами, а как они реализованы внутри уже без разницы.


Что касается конкретно М$СКЛ сервера, то насколько я понимаю, никто его не объявлял абсолютно неправильным только на основании того, что в нем нет триггера BEFORE, его вообще абсолютно неправильным вроде бы не объявляли. Может я пропустил, приведите ссылку. Или не трындите о том, что в сравнении СУБД мало разумных выводов.
5 июл 06, 00:23    [2843048]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Vadim_Maximov
Member

Откуда: Москва
Сообщений: 3571
c127
Вот например еще заморочка появилась в последнее время, типа версионник и блокировочник, они разные, для них нужно все проектировать по-другому и вообще даже сравнивать нельзя. Блин, бред. РСУБД она и в африке РСУБД, для того и придумана теория, чтобы проектировать БД этого класса одинаково. Согласно теории транзакции должны быть и обладать заданными свойствами, а как они реализованы внутри уже без разницы.

Есть теория. А есть суровые жизненные реалии - несколько производителей РСУБД, каждый из которых старается сделать в своей РСУБД сделать что-то, что привлечет покупателей. И у всех получаются в итоге разные "фичи" (читай - концептуальные отличия в архитектуре). И не приспосабливаться к ним - выйдет боком. Однозначно...
5 июл 06, 00:33    [2843063]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
locky
Барин умный - ему виднее... хорошая позиция...
Безусловно, очень конструктивное замечание. Дальше что ? Заставить Microsoft сделать системные таблицы, как мы хотим ? Да они вообще могли закрыть эту информацию, а дать только процедуры для получения текстов. Попробуйте какого-нибудь другого производителя заставить сделать нечто подобное. Безусловно, он, в отличии от MS, радостно кинется вам навстречу и изменит системные вещи так, как нужно именно вам.
Я тоже могу выказывать недовольство, тем более поводов хоть отбавляй, но оно неконструктивно. Надо учиться работать на том, что есть, а не искать все время причины, почему не можешь что-то сделать. Если нужна яма и есть лопата, то надо копать, а не кричать, что нет экскаватора, а вот если бы был, то все ямы нипочем. А потом выяснится, что и на экскаваторе надо уметь работать...
locky
У меня в рабочей базе 584 процы длинее 8000 байт из 17279 штук
584*100/17279 ~ 3.38%. Статистика, однако...
locky
а утиль, кстати - не очень, надо сказать...
Не с чем спорить, нет идеального средства для каждого. Не нравится - нет вопросов, ищите и покупайте. Вы бы в Informix версии 7.3х поработали...
5 июл 06, 00:35    [2843069]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
c127
Guest
Vadim_Maximov
c127
Вот например еще заморочка появилась в последнее время, типа версионник и блокировочник, они разные, для них нужно все проектировать по-другому и вообще даже сравнивать нельзя. Блин, бред. РСУБД она и в африке РСУБД, для того и придумана теория, чтобы проектировать БД этого класса одинаково. Согласно теории транзакции должны быть и обладать заданными свойствами, а как они реализованы внутри уже без разницы.

Есть теория. А есть суровые жизненные реалии - несколько производителей РСУБД, каждый из которых старается сделать в своей РСУБД сделать что-то, что привлечет покупателей. И у всех получаются в итоге разные "фичи" (читай - концептуальные отличия в архитектуре). И не приспосабливаться к ним - выйдет боком. Однозначно...


Неаккуратненько получается. Есть дополнительная фича, привлекает покупателей, т.е. удобно пользоваться, но можно обойтись и стандартными вещами. А потом оказывается, что без нее нельзя, иначе "выйдет боком. Однозначно...". Так это уже не фича, это требование и так и нужно говорить: стандарт не поддерживается, используйте вместо него наше нестандартное.

Если люди заявляют что они производят РСУБД, и более того их РСУБД соответсвует стандартам, то все должно работать так, как это написано в стандартах и в теории.
5 июл 06, 01:04    [2843105]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
ChA
hvlad
Насчёт вышеупомянутых слухов - их легко проверить
Не понял, каких слухов ?
Понял. А зачем ? Мне, собственно, все равно. Или Вы считате, что по этой причине аргументы станут весомее ? Для меня только в том случае, если бы Вы относились к разработчикам MS SQL. Мне было бы что Вам сказать и, поверьте, не только комплименты ;)
А так, если один человек поучаствовал в написании какой-либо программы, это повод считать его экспертом в данной программе, но совсем необязательно во всех аналогичных программах, существующих на рынке.
5 июл 06, 01:42    [2843144]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
ChA
Кстати, а Вы не пробовали в SQL Query Analyzer нажать F4 ? Думаю в большинстве случаев этого было бы вполне достаточно.
Виноват, давно не пользовал, F8, кликаем на объект, далее на Dependencies.
5 июл 06, 04:58    [2843206]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
c127
РСУБД она и в африке РСУБД, для того и придумана теория, чтобы проектировать БД этого класса одинаково. Согласно теории транзакции должны быть и обладать заданными свойствами, а как они реализованы внутри уже без разницы.

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

c127
Если люди заявляют что они производят РСУБД, и более того их РСУБД соответсвует стандартам, то все должно работать так, как это написано в стандартах и в теории.

Хм. Насколько я помню предыдущие обсуждения на этом форуме, для наиболее склоняемых РСУБД - Oracle и MSSQL - были найдены и разобраны места их противоречия стандарту ANSI. Подчеркну: не нереализованности фичи итп, а именно противоречия. Полагаю, этого достаточно, чтобы классифицировать высказанное Вами благое пожелание.
5 июл 06, 07:59    [2843269]     Ответить | Цитировать Сообщить модератору
 Re: Было: простите, накипело  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ChA
статистически, процедур больше 8КБ не так уж много

Бу га га открылась страшная тайна
так вот почему в MS SQL нет пакетов :)
5 июл 06, 08:42    [2843328]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить