ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / А зачем нужен этот монстр....... MS SQL?
25 сообщений из 403, страница 12 из 17
  12  все
А зачем нужен этот монстр....... MS SQL?
    #32755385
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUSПолностью согласен с этим. В ASA например FOREIGN KEY можно вешать не только на первичный, но и любой unique constraint.
В Оракле так же.

ASCRUSВ данном случае первичный ключ обязательно нужен для оператора
Код: plaintext
INSERT INTO Table ... ON EXISTING SKIP|UPDATE|ERROR
который насколько я понимаю является аналогом Оракловского MERGE.
Похоже. Но в MERGE все задается явно - соответственно ключа не требуется.

ASCRUSА вот тут у нас как раз UNIQUE CONSTRAINT не могут делаться на NULL поля (возможно как раз из за возможности FOREIGN KEY по ним).
Здесь Оракл рубанул как Александр по узлу :) И имхо весьма уместно. Оракл постановил, что foreign key может делаться на null поле и ссылаться на null поле - пользуясь идеологией null: условие a.id = b.id не вернет записей, если хоть один из них равен null. Это очень удобно.

Уникальный индекс тоже можно сделать. Но это нужно в основном для функциональных индексов - например,

Код: plaintext
create unique index T_I on T ( upper ( trim ( text_field )))
...
Рейтинг: 0 / 0
26.10.2004, 16:44
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755464
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЗдесь Оракл рубанул как Александр по узлу :) И имхо весьма уместно. Оракл постановил, что foreign key может делаться на null поле и ссылаться на null поле - пользуясь идеологией null: условие a.id = b.id не вернет записей, если хоть один из них равен null. Это очень удобно.
Гм напомнили насчет NULL полей, так что посмотрел в BOL - у нас тоже разрешается использовать UNIQUE INDEX в качестве первичного ключа для связи FOREIGN KEY, потому как разрешается делать FOREIGN KEY для NULL-полей. Правда непонятно, почему в UNIQUE INDEX можно использовать NULL-поля, а в UNIQUE CONSTRAINT нет с учетом того, что они вообще ничем в ASA в архитектурном плане не отличаются. Ну а на вычисляемые поля (выражения) можно делать как UNIQUE CONSTRAINT, так и индексы.

Кстати вспомнил, где еще приятные расширения функциональности связей - это KEY соединения в запросах:
Код: plaintext
1.
2.
3.
SELECT *
FROM Table1
  KEY JOIN Table2
  KEY LEFT JOIN Table3 ON Table3.Value IS NOT NULL;
Если на таблицы есть FOREIGN KEY, если он один, то ASA cама соединит по полям вторичного ключа. В ON в данном случае можно дописать дополнительные условия связи. Такой вид связи таблиц в запросах особенно удачен при построении динамических запросов, текста запроса в клиентском приложении и т.д. ... не нужно замарачиваться с поднятием метаструктуры БД для определения полей связи между таблицами, которые должны быть использованы в запросах. С учетом того, что оптимизатор может выкинуть из запроса неиспользованные, но перечисленные таблицы, вплоть до пересоединения (когда table1->table2->table3 вполне можно было в запросе сократить до table1->table3), то появляются неплохие возможности для создания для клиентских частей всяких поисковых и других механизмов по базе данных.
...
Рейтинг: 0 / 0
26.10.2004, 17:01
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755473
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лох Позорный
Участник
2 softwarer
пользуясь идеологией null: условие a.id = b.id не вернет записей, если хоть один из них равен null
А пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?
...
Рейтинг: 0 / 0
26.10.2004, 17:05
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755481
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
ASA даст и Оракл по моему тоже, исходя из того, что "NULL <> NULL". Хотя это не везде срабатывает, например в ASA для CHECH CONSTRAINT будет верно утверждение "NULL = NULL", сделали специально, чтобы полегче код в них был, все таки этот CONSTRAINT критичный для вставок и обновлений записей.
...
Рейтинг: 0 / 0
26.10.2004, 17:08
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755494
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторА пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?

конечно, если у вас почему-то NULL == NULL то индекс можно строить по NVL()
...
Рейтинг: 0 / 0
26.10.2004, 17:13
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755570
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUS Правда непонятно, почему в UNIQUE INDEX можно использовать NULL-поля, а в UNIQUE CONSTRAINT нет с учетом того, что они вообще ничем в ASA в архитектурном плане не отличаются.
Скорее всего потому, что его следовало бы назвать unique key - то есть в данном случае как раз следуют данному мной определению ключа таблицы. А индекс - это реализация.

ASCRUS Кстати вспомнил, где еще приятные расширения функциональности связей - это KEY соединения в запросах:
Хм. Непривычно :) Я как-то предпочитаю явно указывать, что я хочу. Но вполне логично и соответствует идеологии SQL - так что, наверное, соглашусь с положительной оценкой. Во всяком случае, тут уместно вспомнить, что "фичи лишними не бывают".
...
Рейтинг: 0 / 0
26.10.2004, 17:48
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755577
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Лох ПозорныйА пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?
Даст. В полном соответствии с идеологией. Кстати, интересно было бы посмотреть на задачу, где объективно нужна единственность null в уникальном поле.

P.S. Как Вы вероятно знаете, Oracle экономит место и не хранит в индексах null-овские значения.
...
Рейтинг: 0 / 0
26.10.2004, 17:52
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755610
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторХм. Непривычно :) Я как-то предпочитаю явно указывать, что я хочу. Но вполне логично и соответствует идеологии SQL - так что, наверное, соглашусь с положительной оценкой. Во всяком случае, тут уместно вспомнить, что "фичи лишними не бывают".
Я в данном случае если таблички и так понятно, что соединяются, пишу KEY JOIN, однако в сложных запросах с вложенными запросами или использовании в них представлений и процедур предпочитаю только стандартный JOIN, иначе можно неявно соединить через KEY JOIN явные таблицы запроса и неявные, используемые в представлении или ХП. Еще удобно KEY JOIN-ами с системных таблиц информацию получать, вот уж где вообще замечательно вместе с ними смотрится аггрегатная функция LIST:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SELECT 'CREATE TABLE Table1 (\n' ||
  List('  ' || c.Column_Name || ' ' || 
    MacroSQL_GetTypeColumn(d.Domain_Name, c.Width, c.Scale) || 
    IF c.Nulls = 'N' THEN ' NOT' ENDIF ||
    ' NULL' ||
    IF c."Default" IS NOT NULL THEN 
      IF c.Column_Type = 'C' THEN 
        ' COMPUTE( ' || c."Default" || ')' ELSE 
        ' DEFAULT ' || c."Default" 
      ENDIF
    ENDIF
   , ',\n' ORDER BY c.Column_id) ||
 '\n);' AS Script
FROM SysTable t
  KEY JOIN SysColumn c
  KEY JOIN SysDomain d
WHERE t.table_name = 'Contract_History' AND creator = User_id();
на выходе получим одну запись с полем Script со значением:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CREATE TABLE Table1 (
  Contract_id integer NOT NULL,
  SaveDate date NOT NULL,
  TypeContract_id tinyint NOT NULL,
  Number smallint NOT NULL,
  CloseDate date NULL,
  ContractNumber integer NULL,
  ContractType_id tinyint NOT NULL,
  AdvancePay numeric( 15 ,  2 ) NULL,
  IsAdvancePercent bit NOT NULL,
  c_CloseDate date NOT NULL COMPUTE( IsNull(CloseDate,'2050-01-01')),
  LastUser varchar( 20 ) NOT NULL DEFAULT last user,
  LastTime timestamp NOT NULL DEFAULT timestamp,
  SaveCloseDate date NOT NULL
);
теперь EXECUTE IMMEDIATE и никаких проблем :)
...
Рейтинг: 0 / 0
26.10.2004, 18:08
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755621
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
PL99 vadiminfoВ Оракле эту инфу получить проще. Там есть псевдоколнки OLD и NEW, в которых соответственно значение до и после измения.
Пожалуй, все-таки, это не псевдоколонки, а, если угодно, псевдозаписи.

ASCRUSЯ конечно не претендую на роль знатока Оракла, но по моему там триггеров EACH STATEMENT с возможностью доступа к изменяемой информации нет, все только позаписные (EACH ROW) ?Именно так.
Не очень понятно, что же именно ТАК.

Oracle предлагает - по выбору разработчика, - триггеры на оператор и триггеры на строку. Причем триггеры разделяются еще и по времени выполнения - ДО оператора, ВМЕСТО оператора, ПОСЛЕ оператора. И это если говорить только о части триггеров - о триггерах пользовательских событий.

В триггере на оператор вы можете сбросить данные в другую таблицу и по окнчанию обработки удалить их (их никто и не увидит, если все будет сделано до коммита). По-сути, MS SQL делал примерно то же самое на своих триггерах (псевдо-таблицы inserted и deleted)- триггеров на строку то у него не было. Мне один раз доставило такую мороку!

Сегодня мне трудно сравнивать текущее состояние MS SQL и Oracle - только что вышли новые версии, в них много нового. Но, как разработчик SQL с 1988 года - уже более 15 лет, - могу сказать, что Oracle предоставляет бОльшее количество возможностей для чистых OLTP или для OLTP+хранилище систем. В последнем случае MS SQL вообще имеет архитектурные проблемы, которые он пытается покрыть, бесплатно раздавая Analyse Service.
Но - "мы истории не пишем", поэтому для конкретных проектов гораздо важнее, что разработчик знает твердо, и поэтому все преимущества Oracle могут быть снивелированы одним фактором - незнанием этих преимуществ.

Заглянул с интересом в эту ветку, ожидая найти что-нибудь полезное для себя. Но - дискуссия выродилась в спор о том, "чей язык лучше" - русский или украинский (к примеру). Утонула, так сказать в шуме.
...
Рейтинг: 0 / 0
26.10.2004, 18:13
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755648
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
PiНе очень понятно, что же именно ТАК.
Oracle предлагает ...Поясняю. Oracle не предоставляет стандартных системных средств для доступа к изменяемой информации в Statement Level триггерах, в отличие от MS SQL и ASA.
PiВ триггере на оператор вы можете сбросить данные в другую таблицу и по окнчанию обработки удалить их А вы предлагаете разработчику реализовать этот доступ самостоятельно, причем для каждой таблицы, где такой доступ требуется.
...
Рейтинг: 0 / 0
26.10.2004, 18:20
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755655
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUSЕще удобно KEY JOIN-ами с системных таблиц информацию получать, вот уж где вообще замечательно вместе с ними смотрится аггрегатная функция LIST:
Не очень вижу связь двух тем. Агрегатная функция вроде как должна работать независимо от синтаксиса соединения таблиц :)

Вообще - я вполне согласен отнести эту фичу в разряд комфортабельностей. Можно дальше не убеждать :)

P.S. На всякий случай - такую агрегацию можно сделать и в Оракле :)
...
Рейтинг: 0 / 0
26.10.2004, 18:21
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755767
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ASCRUS
Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

Дело не в споре, а в том, что раз до сих пор споры возникают, существуют недостатки и достоинства того и иного, то ограничения моделирование БД из-за особенностей реализации СУБД, не лучшее из лучшего.
Cуррогатный ключ имеет мало поводов для изменений, но явно реляционная модель не предполагает отсутствия доступа к такому ключу. Если Вы захотите явно запретить изменение этого поля в БД (чтобы повысить неизменяемость) с помощью триггера, что Вы выбирите: псевдозаписи NEW и OLD или опять inserted, updated?

ASCRUS
Есть такое понятие - каскадные триггеры.


Кстати, есть такое понятие каскадное обновление. И вплоть до отмены этого понятия желательно иметь возможность реализовать его как можно проще. Каскадное обновление прописано в разных CASE средствах.
В общем случае разработчику может быть просто дано задание его реализовать, например, руководителем. Причем никаких споров может не допускаться. А Вы говорите концепция отрицает.
...
Рейтинг: 0 / 0
26.10.2004, 19:07
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755778
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
vadiminfo ASCRUS
Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

Дело не в споре, а в том, что раз до сих пор споры возникают, существуют недостатки и достоинства того и иного, то ограничения моделирование БД из-за особенностей реализации СУБД, не лучшее из лучшего.
Cуррогатный ключ имеет мало поводов для изменений, но явно реляционная модель не предполагает отсутствия доступа к такому ключу. Если Вы захотите явно запретить изменение этого поля в БД (чтобы повысить неизменяемость) с помощью триггера, что Вы выбирите: псевдозаписи NEW и OLD или опять inserted, updated?

ASCRUS
Есть такое понятие - каскадные триггеры.


Кстати, есть такое понятие каскадное обновление. И вплоть до отмены этого понятия желательно иметь возможность реализовать его как можно проще. Каскадное обновление прописано в разных CASE средствах.
В общем случае разработчику может быть просто дано задание его реализовать, например, руководителем. Причем никаких споров может не допускаться. А Вы говорите концепция отрицает.
В ASA у меня есть и NEW с OLD, и Inserted с Deleted, и BEFORE с AFTER, и каскадные обновления/удаления и много много чего еще. Так что лично я могу на все Ваши вопросы ответить только одной фразой:
При разработке того или иного решения я постараюсь выбрать здравый смысл и руководствоваться текущими возможностями СУБД :)
...
Рейтинг: 0 / 0
26.10.2004, 19:15
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32755829
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ASCRUS
В ASA у меня есть и NEW с OLD, и Inserted с Deleted, и BEFORE с AFTER, и каскадные обновления/удаления и много много чего еще. Так что лично я могу на все Ваши вопросы ответить только одной фразой:
При разработке того или иного решения я постараюсь выбрать здравый смысл и руководствоваться текущими возможностями СУБД :)

Так вопросы то я задавал с целью уточнения преимуществ и недостатков. То что у Вас есть все эти возможности, то это хорошо. И мне тоже придется руководствоваться текущими возможностями. Хотя мне всегда еще чего-то хочется в плане возможностей. Оракл довольно быстро меняет версии. Народ еще на 9 не пресел с 8, а кое-кто и с 7, а уже 10 есть, но сырая. У нас на фирме поддерживаются 8 и 9, но у меня уже на 8 ломает после 9.
...
Рейтинг: 0 / 0
26.10.2004, 19:48
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32756051
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лох Позорный
Участник
Это хорошо, что ASA и Oracle дадут вставить несколько нуллов в уникальный индекс... А то я уж было начал терять веру в человеков, когда увидел, что MS SQL - не дает. Странная какая-то у них логика, понять бы ее...

softwarerP.S. Как Вы вероятно знаете, Oracle экономит место и не хранит в индексах null-овские значения.
Я опять начинаю терять веру в человеков. С какой стати оракл решил чего то там мне наэкономить? Кто его об этом просил? А если мне понадобится использовать условие Is Null на индексированное уникальное необязательное поле, что, индексом уже никак не получится воспользоваться?
В аксесе, например, включение/невключение Null'ов в индекс - задается в св-вах индекса. Что в общем-то и логично.
...
Рейтинг: 0 / 0
27.10.2004, 07:23
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32756078
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Лох Позорный
Я опять начинаю терять веру в человеков. С какой стати оракл решил чего то там мне наэкономить? Кто его об этом просил? А если мне понадобится использовать условие Is Null на индексированное уникальное необязательное поле, что, индексом уже никак не получится воспользоваться?
В аксесе, например, включение/невключение Null'ов в индекс - задается в св-вах индекса. Что в общем-то и логично.
Не надо терять веру в человечество. В приведенном ниже примере ASA поле VarName обьявленно как NULL, на него сделан уникальный индекс :)
...
Рейтинг: 0 / 0
27.10.2004, 08:17
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32756154
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лох Позорный
Участник
Офф

Все чаще ловлю себя на мысли, что благодаря усилиям ASCRUS'а мне все больше хочется изучить Sybase ASA (и ASE, и PowerBuilder в придачу)
З.Ы. Заголовок у окошка хороший. Zarplata (DBA) on Zarplata. Вот так и живем - зарплата на зарплате.
...
Рейтинг: 0 / 0
27.10.2004, 09:23
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32756267
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЗ.Ы. Заголовок у окошка хороший. Zarplata (DBA) on Zarplata. Вот так и живем - зарплата на зарплате.
Гы - БД Zarplata на сервере Zarplata. У ASA в одноранговой сети не нужно знать имя машины или IP адрес. Говоришь имя сервера, которое ему присвоено в параметрах запуска его сервиса и ни о чем не думаешь. Очень удобно так сервер с машины на машину переносить, никто с клиентов даже и не заметит :)

авторВсе чаще ловлю себя на мысли, что благодаря усилиям ASCRUS'а мне все больше хочется изучить Sybase ASA (и ASE, и PowerBuilder в придачу)
Вот насчет ASE не знаю конечно, сильно она мне неуклюжей по функциональности кажется (не в обиду будь ей сказано), а вот Вам, работающему на связке Access + MSSQL перейти на связку ASA + PowerBuilder что раз плюнуть - ASA легче MSSQL в плане изучения, так как у ней архитектура другая, меньше граблей и больше возможностей (естественно мое личное мнение), а PowerBuilder - так это вообще просто можно представить себе Access у которого например формы данных и отчеты хранятся в виде XML описания, которое легко изменять в рунтайме (включая контролсы на нем) через специальный интрепретирующий язык , навешивать на свойства контролсов и бандов выражения, поддерживается в полной мере ООП для создания повторно наследуемых компонентов и форм, в самом языке можно использовать встроенный SQL и весь доступ к БД сделан прозрачно, где при подключении сессии достаточно указать протокол работы (ADO, ODBC, OLEDB, JDBC и т.д.), а в самой программе коду все равно, какой там протокол сейчас установлен. Как все это представите в Access - как раз и получите PowerBuilder (PowerScript кстати этакая смешная помесь VB и Smalltalk).

Так что если время свободное есть - welcome, скачать, посмотреть и обьяснения на наших форумах получить недолго хотя бы для собственного самообразования и расширения кругозора, не всеж в одной MS коллее сидеть :)
...
Рейтинг: 0 / 0
27.10.2004, 10:20
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757120
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
PL99 PiНе очень понятно, что же именно ТАК.
Oracle предлагает ...Поясняю. Oracle не предоставляет стандартных системных средств для доступа к изменяемой информации в Statement Level триггерах, в отличие от MS SQL и ASA.
PiВ триггере на оператор вы можете сбросить данные в другую таблицу и по окнчанию обработки удалить их А вы предлагаете разработчику реализовать этот доступ самостоятельно, причем для каждой таблицы, где такой доступ требуется.
to PL99

Вы как бы правы. Но для сторонних я ситуацию поясню.

Oracle не предоставляет стандартных системных средств для доступа к изменяемой информации в Statement Level триггерах поскольку в Oracle есть триггер Row Level - и там все делается на раз.

MS SQL предоставляет стандартное системное средство для доступа к изменяемой информации в Statement Level, ибо других триггеров у него нет . И, как бы это не звучало для неприятно для некоторых, в общем случае здесь можно заработать геморрой (например, когда надо будет сделать что-либо серьезное, особенно в чужом приложении). Простите за откровенность, но именно такой случай у меня случился, еще в 2000 году. Нужно было всего-то дописать аудит ...

То, что разработчик может сделать в Oracle на Statement Level имеет лишь одно маленькое отличие - таблицу надо создать самому и записи туда сбросить самому. Я считаю это отличие маленьким, поскольку создать таблицу типа ТаЖеСамаяТаблица _Лог + оператор Insert в теле триггера - это детская забава по сравнению с написанием бизнес-кода + его отладкой + его тестированием + его сдачей + его переопределением + его перепиской +...+...

Безусловно, это сугубо личное мнение. В конечном счете кому-то и Oracle sequence кажется умопомрачительно более трудоемким, чем identity в MS SQL ;)
...
Рейтинг: 0 / 0
27.10.2004, 14:23
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757349
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Pi считаю это отличие маленьким, поскольку создать таблицу типа ТаЖеСамаяТаблица_Лог + оператор Insert в теле триггера - это детская забава по сравнению с написанием бизнес-кода + его отладкой + его тестированием + его сдачей + его переопределением + его перепиской +...+...
Ну тогда можно сказать что и между Ораклом и МС СКЛ различий почти нет :)

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

Вот например триггер на удаления дерева c подветками для MS SQL (предполагается что стоит рекурсивный вызов триггеров)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
create table tree(id int identity, parent int null, caption varchar( 55 ))

go

create trigger ttt om tree for delete as
begin
if not exists(select * from deleted) return
delete t
  from tree t, deleted d
  where d.id=t.parent
end
Может еще кто напишет примеры для других СУБД, для других задач? Главное чтоб были короткие и понятные.
...
Рейтинг: 0 / 0
27.10.2004, 15:40
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757413
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
На ASA для деревьев код не потребуется. Просто делается FOREIGN KEY Parent_id->id с опциями CHECK ON COMMIT и CASCADE DELETE. Для различной обработки деревьев можно пользоваться рекурсивными запросами "WITH RECURSIVE" (синтаксис аналогичный DB2).
...
Рейтинг: 0 / 0
27.10.2004, 16:02
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757531
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лох Позорный
Участник
ээээ...
дык ведь в MS SQL тоже можно сделать On Delete Cascade?
...
Рейтинг: 0 / 0
27.10.2004, 16:43
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757578
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Конечно можно :) Вот только насчет "CHECK ON COMMIT" (отложенная проверка до COMMIT) по моему там туго. А опция эта иногда здорово помогает, когда ссылочная целостность может быть достигнута не во время выполнения каждого оператора DML, а по окончании транзакции, что в принципе впервую очередь к деревьям и относиться.
...
Рейтинг: 0 / 0
27.10.2004, 16:55
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32757609
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Какая разница можно или нет? Пример же просто как работать в триггере с записями той же таблицы.
Ведь далеко не всё можно сделать через FOREIGN KEY
...
Рейтинг: 0 / 0
27.10.2004, 17:01
| Ответить | Цитировать | Написать  
А зачем нужен этот монстр....... MS SQL?
    #32758148
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ASCRUS
Для различной обработки деревьев можно пользоваться рекурсивными запросами "WITH RECURSIVE" (синтаксис аналогичный DB2).

В Оракле тоже есть иерархические запросы. Например, чтобы удалить узел id = 1 со всеми потомками из примера, который привел SergSuper можно выполнить DML:

DELETE FROM Tree
WHERE id IN (SELECT id FROM tree
START WITH id = 1
CONNECT BY PRIOR id = parent)
...
Рейтинг: 0 / 0
27.10.2004, 23:46
| Ответить | Цитировать | Написать  
25 сообщений из 403, страница 12 из 17
  12  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / А зачем нужен этот монстр....... MS SQL?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]