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

Откуда: Москва
Сообщений: 504
Давайте разберемся по пунктам
1.
gardenman
странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2
что значит уже реализоваЛА?
В статье Сможет ли Stinger затмить Yukon? есть фраза: "Во всех статьях рассказывалось о предстоящем выпуске DB2 UDB 8.2 (условное название Stinger) осенью 2005 г.". Или я что-то пропустил?

2. По поводу интеграции .Net Framework и SQL2k5 есть хорошая презентация (Программирование для SQL Server 2005 с использованием .NET Framework 2.0), раскрывающая смысл такой интеграции, возможности, а также рекомендации на тему когда использовать T-SQL а когда .Net языки. От себя могу добавить (если кто поленится скачать), что для работы с данными (select/insert/update/delete) конечно ничего в MS SQL Server не будет быстрее T-SQL. Однако, если в процедуре нам нужен цикл, например, или другая подобная логика, отходящая от перечисленных выше команд, то такая процедура прямой кандидат для реализации на .Net. И она будет работать намного быстрее, даже на SQL2k5 beta2. Несмотря на то, что .Net будет работать с СУБД в одном процессе, как это не парадоксально для некоторых звучит, это не снизит производительность СУБД. Потом убедитесь сами. К тому же эту функциональность можно и не включать (по умолчанию Microsoft .NET Framework выключен).

3. По поводу "забытости" компанией T-SQL. На этом же сайте, благодаря Александру Гладченко, есть замечательная подборка материалов по SQL2k5. В частности, там есть большая статья T-SQL Enhancements in SQL Server 2005.
8 дек 04, 15:50    [1167409]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
segun
Давайте разберемся по пунктам
1.
gardenman
странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2
что значит уже реализоваЛА?
В статье Сможет ли Stinger затмить Yukon? есть фраза: "Во всех статьях рассказывалось о предстоящем выпуске DB2 UDB 8.2 (условное название Stinger) осенью 2005 г.". Или я что-то пропустил?


DB2 v8.2 находится в продаже с сентября этого года. Если есть желание, можете взять триальную версию с сайта ИБМ
8 дек 04, 16:28    [1167560]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Наверное это опечатка...
Кстати Oracle после выхода Stinger сделал анонс что тоже реализует такую функциональность правда когда не сказал...
8 дек 04, 16:32    [1167576]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а MS триггера before так и не собираются делать?..
8 дек 04, 16:32    [1167578]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
на счет .Net: http://www-128.ibm.com/developerworks/db2/library/techarticle/0304alazzawe/0304alazzawe.html
8 дек 04, 16:38    [1167602]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
gardenman
а MS триггера before так и не собираются делать?..
ИМХО, необходимость в BEFORE-триггере вполне перекрывается INSTEAD-триггерами. По крайней мере, я не смог придумать ситуацию, в которой BEFORE-триггер оказался бы существенно более полезным, нежели INSTEAD. Пусть меня поправят, если я не прав.
8 дек 04, 17:39    [1167870]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
странно, в других базах ORACLE,DB2 нашлось место и тем и другим...
8 дек 04, 17:45    [1167888]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а триггеры на уровне строки тоже не нужны?... печально...
8 дек 04, 17:47    [1167896]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
8 дек 04, 17:47    [1167901]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
segun
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before

Хм. Я затруднюсь придумать ситуацию, в которой нельзя обойтись вообще без триггеров. Но это не повод их не делать.
8 дек 04, 17:51    [1167912]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
gardenman
странно, в других базах ORACLE,DB2 нашлось место и тем и другим...
я нашел пример, но врядли он вам понравится. это облегчение миграции с СУБД, в которых он реализован. На самом деле я не противник дополнительной функциональности, больше фич хороших и разных! Но так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д., и, с учетом этого, до сих пор нет триггеров before - это означает лишь одно. Пока есть более приоритетные вещи, чем эта разновидность триггеров. Значит они не так нужны при разработке решений на SQL Server, либо хорошо заменяются триггерами instead.
8 дек 04, 18:09    [1167998]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
автор
Но так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д....


И вы думаете, что им важны ваши пожелания... :)

Картинка с другого сайта.
8 дек 04, 18:49    [1168093]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
nik_x
Member

Откуда:
Сообщений: 1887
segun
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before


Ну например, вместо удаления записи, она переносится в архив.
8 дек 04, 19:15    [1168145]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Рыжий Кот

И вы думаете, что им важны ваши пожелания... :)

Картинка с другого сайта.
да. очень. и я не думаю, я знаю. или думаю что знаю. :)
не хочу никого лечить, но, на мой взгляд, на сегодняшний день это одна из самых открытых компаний-разработчиков ПО.
Кстати, если кто не знает, есть интересный сайт о том как создаются продукты в MS
8 дек 04, 19:19    [1168152]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
nik_x
segun
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
Ну например, вместо удаления записи, она переносится в архив.
как переносится, физически? то есть в другую таблицу или секцию, если мы говорим о секционированной таблице?
Или удаление подразумевает просто обновление статуса записи?
Напишите немного подробнее пожалуйста.
8 дек 04, 19:27    [1168164]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
nik_x
segun
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before

Ну например, вместо удаления записи, она переносится в архив.

Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead.
Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально?
9 дек 04, 00:47    [1168444]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
SergSuper
nik_x
segun
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before

Ну например, вместо удаления записи, она переносится в архив.

Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead.
Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально?


Уважаемый SegrSuper. У вас есть хорошая возможность меня убедить в том, что триггеры INSTEAD действительно могут заменить триггеры BEFORE.

Задача: имеется 2 таблицы
1) Проводки (id проводки,счет, сумма, дата)
2) Журнал_ движения (счет, дата, сумма оборотов за день)

реализовать:
1) При добавлении записи в журнал движения по счету сумма оборотов за день формируется как select sum(сумма) from Проводки where Проводки.счет=
Журнал_движения.счет и Проводки.дата=Журнал_движения.дата
2) при добавлении в таблицу Проводок записи, если уже сформирован журнал движения, то возвращается ошибка.
3) если существует журнал движения за конкретную дату, то нельзя удалить запись в таблице проводок за эту дату, т.е. сначала должен быть удален журнал проводок.
Реализовать всю схему без использования ХП,исключительно на триггерах
9 дек 04, 10:42    [1168939]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 gardenman
А зачем тут before триггеры? Во всяком случае у меня несколько более сложная схема проводок (наверняка и Вы тут упростили свою задачу) и всё на триггерах after.
9 дек 04, 10:58    [1169027]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Да, я упростил до невозможности.
первый триггер Before должен проинициализировать сумму в таблице движения до вставки записи.
второй триггер before должен возвратить ошибку до вставки в таблицу проводок
9 дек 04, 11:10    [1169090]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
и еще вопросик, сколько тригеров INSTEAD OF INSERT одновременно может висеть на одной таблице?
9 дек 04, 11:13    [1169114]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
e60
Member

Откуда:
Сообщений: 89
ИМХО практика доказала, что все в одном (Сервак приложений и СУБД) рассчитано на универсальность, что означает потерю производительности.
Моя мнение такое должна быть СУБД с SQL и отдельный Application Server. Ведь это распределнная логика, которая быстрее по своей сути.
Вот пример:
Есть СУБД и несколько клиентских программ. Скажем так одни клиентские приложения используют простые запросы для получения текущей информации, а другие клиенты используют сложные запросы + доп возможности .NET и т.п.
При распределении простые приложения будут общаться напрямую с СУБД, а сложные через сервер приложений.
Если же будет все в одном, то и те и другие будут задействовать и СУБД и сервер приложений
9 дек 04, 12:04    [1169354]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
2gardenman: 99.99% всех задач, реализованных на DB2, Oracle или другой RDBMS можно сделать на SQLServer без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью SQLServer? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью хранимых процедур или триггеров instead of. Неясно, по какой причине вы сразу отклонили использование процедур, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность SQLServer. Я же вас не спрашиваю, почему уязвимостей в безопасности Oracle больше чем в SQLServer.

По поводу кол-ва триггеров instead of insert на одной таблице - ответ 1. И тем не менее я не думаю что это повод для баталий.

Мы живем в интересное время когда конкуренция между основными лидерами RDBMS + mySQL заставляет компаний-разработчиков дополнять свои продукты все новыми и новыми возможностями. И это касается не только SQLServer. Например Oracle говорит о том что до выхода 10g все было классно, за исключением, может быть, управляемости. И теперь все стало еще лучше. Значит всем, а не только SQLServer есть куда стремиться? На мой взгляд, это нормальное развитие ситуации.
9 дек 04, 12:08    [1169378]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
e60
Member

Откуда:
Сообщений: 89
segun
2gardenman: 99.99% всех задач, реализованных на DB2, Oracle или другой RDBMS можно сделать на SQLServer без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью SQLServer? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью хранимых процедур или триггеров instead of. Неясно, по какой причине вы сразу отклонили использование процедур, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность SQLServer. Я же вас не спрашиваю, почему уязвимостей в безопасности Oracle больше чем в SQLServer.

По поводу кол-ва триггеров instead of insert на одной таблице - ответ 1. И тем не менее я не думаю что это повод для баталий.

Мы живем в интересное время когда конкуренция между основными лидерами RDBMS + mySQL заставляет компаний-разработчиков дополнять свои продукты все новыми и новыми возможностями. И это касается не только SQLServer. Например Oracle говорит о том что до выхода 10g все было классно, за исключением, может быть, управляемости. И теперь все стало еще лучше. Значит всем, а не только SQLServer есть куда стремиться? На мой взгляд, это нормальное развитие ситуации.

Ну по-поводу уязвимости это Вы загнули. SQLServer - на MS Windows, котороая по сути уязвимей, чем *nix системы. А если уязвима ОС, то вы на нее хоть черта ставьте - не поможет
9 дек 04, 12:18    [1169444]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Yo!
Guest
мда .. меняем mssql на mysql а оракл на mssql и понимаем какую чушь пороли :)

--------
99.99% всех задач, реализованных на mssql или другой RDBMS можно сделать на mysql без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью mysql ? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью выноса логики на апп-сервер.Неясно, по какой причине вы сразу отклонили использование апп-сервера, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность mysql. Я же вас не спрашиваю, почему уязвимостей в безопасности mssql больше чем в mysql.
--------

ЗЫ. mssql это пока единственная субд добившееся действительно впечатляющих результатов в области секурити - это единственая субд с вирусами на пару дней вывела из строя целый регион. такое еще никому не удавалось.
9 дек 04, 12:24    [1169484]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Приведите, пожалуйста, ссылки на независимые компании в которых были проведены эти исследования. Например, за 2003-2004 годы.
9 дек 04, 12:24    [1169485]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить