Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
ASCRUS
Полностью согласен с этим. В ASA например FOREIGN KEY можно вешать не только на первичный, но и любой unique constraint.

В Оракле так же.

ASCRUS
В данном случае первичный ключ обязательно нужен для оператора
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. Это очень удобно.

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

create unique index T_I on T ( upper ( trim ( text_field )))
26 окт 04, 16:44    [1062295]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Здесь Оракл рубанул как Александр по узлу :) И имхо весьма уместно. Оракл постановил, что 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 соединения в запросах:
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), то появляются неплохие возможности для создания для клиентских частей всяких поисковых и других механизмов по базе данных.
26 окт 04, 17:01    [1062417]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 softwarer
пользуясь идеологией null: условие a.id = b.id не вернет записей, если хоть один из них равен null

А пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?
26 окт 04, 17:05    [1062436]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ASA даст и Оракл по моему тоже, исходя из того, что "NULL <> NULL". Хотя это не везде срабатывает, например в ASA для CHECH CONSTRAINT будет верно утверждение "NULL = NULL", сделали специально, чтобы полегче код в них был, все таки этот CONSTRAINT критичный для вставок и обновлений записей.
26 окт 04, 17:08    [1062453]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
автор
А пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?


конечно, если у вас почему-то NULL == NULL то индекс можно строить по NVL()
26 окт 04, 17:13    [1062481]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
ASCRUS
Правда непонятно, почему в UNIQUE INDEX можно использовать NULL-поля, а в UNIQUE CONSTRAINT нет с учетом того, что они вообще ничем в ASA в архитектурном плане не отличаются.

Скорее всего потому, что его следовало бы назвать unique key - то есть в данном случае как раз следуют данному мной определению ключа таблицы. А индекс - это реализация.

ASCRUS
Кстати вспомнил, где еще приятные расширения функциональности связей - это KEY соединения в запросах:

Хм. Непривычно :) Я как-то предпочитаю явно указывать, что я хочу. Но вполне логично и соответствует идеологии SQL - так что, наверное, соглашусь с положительной оценкой. Во всяком случае, тут уместно вспомнить, что "фичи лишними не бывают".
26 окт 04, 17:48    [1062629]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
Лох Позорный
А пользуясь этой чудесной идеологией - мудрый Оракл даст создать несколько записей, содержащих Null в необязательном поле, по которому построен уникальный индекс?

Даст. В полном соответствии с идеологией. Кстати, интересно было бы посмотреть на задачу, где объективно нужна единственность null в уникальном поле.

P.S. Как Вы вероятно знаете, Oracle экономит место и не хранит в индексах null-овские значения.
26 окт 04, 17:52    [1062648]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Хм. Непривычно :) Я как-то предпочитаю явно указывать, что я хочу. Но вполне логично и соответствует идеологии SQL - так что, наверное, соглашусь с положительной оценкой. Во всяком случае, тут уместно вспомнить, что "фичи лишними не бывают".

Я в данном случае если таблички и так понятно, что соединяются, пишу KEY JOIN, однако в сложных запросах с вложенными запросами или использовании в них представлений и процедур предпочитаю только стандартный JOIN, иначе можно неявно соединить через KEY JOIN явные таблицы запроса и неявные, используемые в представлении или ХП. Еще удобно KEY JOIN-ами с системных таблиц информацию получать, вот уж где вообще замечательно вместе с ними смотрится аггрегатная функция LIST:
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 со значением:
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 и никаких проблем :)
26 окт 04, 18:08    [1062714]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

Откуда:
Сообщений: 278
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 могут быть снивелированы одним фактором - незнанием этих преимуществ.

Заглянул с интересом в эту ветку, ожидая найти что-нибудь полезное для себя. Но - дискуссия выродилась в спор о том, "чей язык лучше" - русский или украинский (к примеру). Утонула, так сказать в шуме.
26 окт 04, 18:13    [1062734]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
Pi
Не очень понятно, что же именно ТАК.
Oracle предлагает ...
Поясняю. Oracle не предоставляет стандартных системных средств для доступа к изменяемой информации в Statement Level триггерах, в отличие от MS SQL и ASA.
Pi
В триггере на оператор вы можете сбросить данные в другую таблицу и по окнчанию обработки удалить их
А вы предлагаете разработчику реализовать этот доступ самостоятельно, причем для каждой таблицы, где такой доступ требуется.
26 окт 04, 18:20    [1062768]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
ASCRUS
Еще удобно KEY JOIN-ами с системных таблиц информацию получать, вот уж где вообще замечательно вместе с ними смотрится аггрегатная функция LIST:

Не очень вижу связь двух тем. Агрегатная функция вроде как должна работать независимо от синтаксиса соединения таблиц :)

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

P.S. На всякий случай - такую агрегацию можно сделать и в Оракле :)
26 окт 04, 18:21    [1062776]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

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

ASCRUS

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


Кстати, есть такое понятие каскадное обновление. И вплоть до отмены этого понятия желательно иметь возможность реализовать его как можно проще. Каскадное обновление прописано в разных CASE средствах.
В общем случае разработчику может быть просто дано задание его реализовать, например, руководителем. Причем никаких споров может не допускаться. А Вы говорите концепция отрицает.
26 окт 04, 19:07    [1062919]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
vadiminfo
ASCRUS

Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

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

ASCRUS

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


Кстати, есть такое понятие каскадное обновление. И вплоть до отмены этого понятия желательно иметь возможность реализовать его как можно проще. Каскадное обновление прописано в разных CASE средствах.
В общем случае разработчику может быть просто дано задание его реализовать, например, руководителем. Причем никаких споров может не допускаться. А Вы говорите концепция отрицает.

В ASA у меня есть и NEW с OLD, и Inserted с Deleted, и BEFORE с AFTER, и каскадные обновления/удаления и много много чего еще. Так что лично я могу на все Ваши вопросы ответить только одной фразой:
При разработке того или иного решения я постараюсь выбрать здравый смысл и руководствоваться текущими возможностями СУБД :)
26 окт 04, 19:15    [1062930]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

В ASA у меня есть и NEW с OLD, и Inserted с Deleted, и BEFORE с AFTER, и каскадные обновления/удаления и много много чего еще. Так что лично я могу на все Ваши вопросы ответить только одной фразой:
При разработке того или иного решения я постараюсь выбрать здравый смысл и руководствоваться текущими возможностями СУБД :)

Так вопросы то я задавал с целью уточнения преимуществ и недостатков. То что у Вас есть все эти возможности, то это хорошо. И мне тоже придется руководствоваться текущими возможностями. Хотя мне всегда еще чего-то хочется в плане возможностей. Оракл довольно быстро меняет версии. Народ еще на 9 не пресел с 8, а кое-кто и с 7, а уже 10 есть, но сырая. У нас на фирме поддерживаются 8 и 9, но у меня уже на 8 ломает после 9.
26 окт 04, 19:48    [1062988]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Это хорошо, что ASA и Oracle дадут вставить несколько нуллов в уникальный индекс... А то я уж было начал терять веру в человеков, когда увидел, что MS SQL - не дает. Странная какая-то у них логика, понять бы ее...

softwarer
P.S. Как Вы вероятно знаете, Oracle экономит место и не хранит в индексах null-овские значения.

Я опять начинаю терять веру в человеков. С какой стати оракл решил чего то там мне наэкономить? Кто его об этом просил? А если мне понадобится использовать условие Is Null на индексированное уникальное необязательное поле, что, индексом уже никак не получится воспользоваться?
В аксесе, например, включение/невключение Null'ов в индекс - задается в св-вах индекса. Что в общем-то и логично.
27 окт 04, 07:23    [1063314]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Лох Позорный

Я опять начинаю терять веру в человеков. С какой стати оракл решил чего то там мне наэкономить? Кто его об этом просил? А если мне понадобится использовать условие Is Null на индексированное уникальное необязательное поле, что, индексом уже никак не получится воспользоваться?
В аксесе, например, включение/невключение Null'ов в индекс - задается в св-вах индекса. Что в общем-то и логично.

Не надо терять веру в человечество. В приведенном ниже примере ASA поле VarName обьявленно как NULL, на него сделан уникальный индекс :)

К сообщению приложен файл. Размер - 0Kb
27 окт 04, 08:17    [1063349]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Офф

Все чаще ловлю себя на мысли, что благодаря усилиям ASCRUS'а мне все больше хочется изучить Sybase ASA (и ASE, и PowerBuilder в придачу)
З.Ы. Заголовок у окошка хороший. Zarplata (DBA) on Zarplata. Вот так и живем - зарплата на зарплате.
27 окт 04, 09:23    [1063493]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
З.Ы. Заголовок у окошка хороший. 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 коллее сидеть :)
27 окт 04, 10:20    [1063664]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Pi
Member

Откуда:
Сообщений: 278
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 ;)
27 окт 04, 14:23    [1065007]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Pi
считаю это отличие маленьким, поскольку создать таблицу типа ТаЖеСамаяТаблица_Лог + оператор Insert в теле триггера - это детская забава по сравнению с написанием бизнес-кода + его отладкой + его тестированием + его сдачей + его переопределением + его перепиской +...+...

Ну тогда можно сказать что и между Ораклом и МС СКЛ различий почти нет :)

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

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

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
Может еще кто напишет примеры для других СУБД, для других задач? Главное чтоб были короткие и понятные.
27 окт 04, 15:40    [1065389]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
На ASA для деревьев код не потребуется. Просто делается FOREIGN KEY Parent_id->id с опциями CHECK ON COMMIT и CASCADE DELETE. Для различной обработки деревьев можно пользоваться рекурсивными запросами "WITH RECURSIVE" (синтаксис аналогичный DB2).
27 окт 04, 16:02    [1065500]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
ээээ...
дык ведь в MS SQL тоже можно сделать On Delete Cascade?
27 окт 04, 16:43    [1065666]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Конечно можно :) Вот только насчет "CHECK ON COMMIT" (отложенная проверка до COMMIT) по моему там туго. А опция эта иногда здорово помогает, когда ссылочная целостность может быть достигнута не во время выполнения каждого оператора DML, а по окончании транзакции, что в принципе впервую очередь к деревьям и относиться.
27 окт 04, 16:55    [1065730]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Какая разница можно или нет? Пример же просто как работать в триггере с записями той же таблицы.
Ведь далеко не всё можно сделать через FOREIGN KEY
27 окт 04, 17:01    [1065775]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
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)
27 окт 04, 23:46    [1066654]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить