Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
aZm
И в чём "лучшесть" ?
Ранее уже приводили список.

Полистал MSDN по поводу программирования SQLServer2005
CLR User-Defined Types (CLR UDT). Не уверен, что Oracle поддерживает это для .NET. На сколько это удобно/не удобно надо/не надо - это другой вопрос (однозначно ответить нельзя).

aZm
2 Dooma
механизм перевода суммы в пропись можно реализовать чистым SQL по идее, вместо массивов - справочники настроек по разным языкам.
Безусловно, все возможно.
Но, во-первых, живя в России, я в своей практике ни разу не сталкивался с необходимостью выводить суммы прописью на английском или каком-нибудь другом иностранном языке.
Во-вторых, если хотите я пришлю вам эти процедуры, вы попробуете их перевести на таблички, выделяя языковые особенности и посмотрим на сколько быстрее это будет у вас работать. Я что-то сомневаюсь в рациональности такой нормализации. Хотя может вам и удасться меня переубедить.
11 ноя 05, 14:43    [2060457]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Dooma
aZm
И в чём "лучшесть" ?
Ранее уже приводили список.

Полистал MSDN по поводу программирования SQLServer2005
CLR User-Defined Types (CLR UDT). Не уверен, что Oracle поддерживает это для .NET. На сколько это удобно/не удобно надо/не надо - это другой вопрос (однозначно ответить нельзя).

Опять на Оракл... В MS SQL гораздо больше нет того, что есть в Оракле.
Вам то чем будет удобен CLR UDT? Чего мы высшими материями всё говорим. Может и нужная вещь, я но не знаю как её использовать, может Вы знаете - напишите.
aZm
2 Dooma
механизм перевода суммы в пропись можно реализовать чистым SQL по идее, вместо массивов - справочники настроек по разным языкам.
Безусловно, все возможно.
Но, во-первых, живя в России, я в своей практике ни разу не сталкивался с необходимостью выводить суммы прописью на английском или каком-нибудь другом иностранном языке.
Во-вторых, если хотите я пришлю вам эти процедуры, вы попробуете их перевести на таблички, выделяя языковые особенности и посмотрим на сколько быстрее это будет у вас работать. Я что-то сомневаюсь в рациональности такой нормализации. Хотя может вам и удасться меня переубедить.[/quot]
У меня функция суммы прописью на SQL занимает ровно 30 строчек. 1000 сумму переводит меньше чем за секудну. Так что пример неудачный.
Что еще нужно кроме этих функций? Ну разве что посылку почты. Может какой-то специфический разбор слов, т.е. для очень специфических систем. Но в таких случаях можно и хр_процедуру написать
11 ноя 05, 15:15    [2060655]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

SergSuper wrote:
> У меня функция суммы прописью на SQL занимает ровно 30 строчек. 1000
> сумму переводит меньше чем за секудну. Так что пример неудачный.
Аналогично. Правда, у нас сумма прописью выводится не очень часто, так
что скорость - некритична. Мож, у них наоборот?

> Что еще нужно кроме этих функций? Ну разве что посылку почты. Может
> какой-то специфический разбор слов, т.е. для очень специфических систем.
> Но в таких случаях можно и хр_процедуру написать
>
дык вот из-за таких вот случаёв, как говорится... ваще-то, CLR - куды
лучшее, чем ESP... ширее, надёжнее (вроде я так понял)...

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

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 15:54    [2060967]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

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

зы слова о том, что теперь можно отлаживать процедуры сервера на студии - простите, а вы студию покупаете? цены знаете? и если пишете на связке MSSQL+Delphi к примеру, будете ее покупать? не смешите мои тапки :)

---
Vae victis!
11 ноя 05, 15:56    [2060980]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
locky


дык вот из-за таких вот случаёв, как говорится... ваще-то, CLR - куды
лучшее, чем ESP... ширее, надёжнее (вроде я так понял)...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3


тяжелее, глючнее, сложнее... хотя мне пофиг) ну включили эту .Net. ну и пофигу на нее. пока не возникнет задача, которую по другому не решить - я и пробовать это не буду. ибо - согласен с кайтом ))))
11 ноя 05, 15:59    [2061002]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

aZm wrote:
> тяжелее, глючнее, сложнее... хотя мне пофиг) ну включили эту .Net. ну и
> пофигу на нее. пока не возникнет задача, которую по другому не решить -
> я и пробовать это не буду. ибо - согласен с кайтом ))))
если мне не изменяет маразма, как бы сам сервер не был на йетом
точка-сети написан :-( так шо тяжелее чем он есть - не будит...
Да и попроще и поудобнее всё-же процы лепить на си-шарпе, чем
выделываться с ODS - ой, как попроще...

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

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 16:12    [2061088]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
locky

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


мои соболезнования :(

locky

Да и попроще и поудобнее всё-же процы лепить на си-шарпе, чем
выделываться с ODS - ой, как попроще...


а может, все же на транзакте ;)?
11 ноя 05, 16:15    [2061111]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2с127
Меня собственно маркетинговые лозунги MS мало интересуют. Пусть кричат, если хочется.
Я для себя достаточно четко представляют основные плюсы и минусы, а также области, в которых MS сделала прорыв (для самой MS) и которые мне интересны.

Интеграция с CLR - это далеко не самое первое из того, что я ждал в Юконе.
11 ноя 05, 16:20    [2061146]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

aZm wrote:
>
> а может, все же на транзакте ;)?

вот Вы мне сообразите, как на транзакте поженить VDI и unrar.dll, тады
ладно, а пока - приходиться так вот мучиться...

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

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 16:21    [2061152]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
SergSuper
Опять на Оракл...
Разговор был про разницу в .NET интеграции. А не про что-то другое. Сами в сторону не уводите.

SergSuper
У меня функция суммы прописью на SQL занимает ровно 30 строчек. 1000 сумму переводит меньше чем за секудну. Так что пример неудачный.
Ну и что? А уменя выходит быстрее.
7000 строк перевела за ~800 ms с учетом склонений по родам.
Может и мне такая скорость не нужна, но еще раз повторюсь, что на C# она будет выглядеть красивее, и, скорее всего, еще быстрее.

aZm
зы слова о том, что теперь можно отлаживать процедуры сервера на студии - простите, а вы студию покупаете? цены знаете? и если пишете на связке MSSQL+Delphi к примеру, будете ее покупать? не смешите мои тапки :)
Пусть ваши тапки смеются :) У нас VS куплена официально
11 ноя 05, 16:27    [2061194]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
locky

вот Вы мне сообразите, как на транзакте поженить VDI и unrar.dll, тады
ладно, а пока - приходиться так вот мучиться...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3


а это как раз из тех 5-10% задачек не свойственных серверу :) для которых java/.Net и будет хорошим решением если не выносить за сервер это, конечно.
11 ноя 05, 16:29    [2061210]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

aZm wrote:
> а это как раз из тех 5-10% задачек не свойственных серверу :) для
> которых java/.Net и будет хорошим решением если не выносить за сервер
> это, конечно.
скажем, даже не 5-10%, а куда меньше... и за сервер это, увы, не
вынесешь, потому как юзается дла восстановления баз.

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

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 16:37    [2061260]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Guest_333
Guest
AAron
Я для себя достаточно четко представляют основные плюсы и минусы, а также области, в которых MS сделала прорыв (для самой MS) и которые мне интересны.

А поподробнее можно?
11 ноя 05, 16:40    [2061280]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2Guest_333
Многое из этого было сказано, втч и в этом топике. Нет желания переливать из пустого в порожнее, т.к. толка не будет.
11 ноя 05, 16:47    [2061320]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Dooma
Разговор был про разницу в .NET интеграции. А не про что-то другое. Сами в сторону не уводите.

Разговор был что некие .NET программисты предпочтут MS ораклу из-за лучшей интеграции. Дык вот и хотелось бы увидеть что даёт эта интеграция, что бы остальные преимущества оракла были не нужны. Пока дальше суммы прописью не ушло. А преимущества её писать на .Нете неочевидны: скорость, как Вы сами признали, не критична, а красивость понятие субъективное - у меня например было когда-то написано на Паскале - я бы не сказал что было красивей. А вот то что мне для любых исправленией в этой функции одного QA уже маловато будет - это уже объективно.
11 ноя 05, 16:49    [2061338]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Gluk (Kazan)
Member

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

скажем, даже не 5-10%, а куда меньше... и за сервер это, увы, не
вынесешь, потому как юзается дла восстановления баз.


Мои соболезнования :( (с)
11 ноя 05, 17:18    [2061457]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
SergSuper
Разговор был что некие .NET программисты предпочтут MS ораклу из-за лучшей интеграции. Дык вот и хотелось бы увидеть что даёт эта интеграция, что бы остальные преимущества оракла были не нужны. Пока дальше суммы прописью не ушло. А преимущества её писать на .Нете неочевидны: скорость, как Вы сами признали, не критична, а красивость понятие субъективное - у меня например было когда-то написано на Паскале - я бы не сказал что было красивей. А вот то что мне для любых исправленией в этой функции одного QA уже маловато будет - это уже объективно.

Я привел этот пример, как пример строчной обработки.
Можно представить задачи, где скорость строчной обработки или сложных математических вычислений над данными все же существенна. Там, очевидно, такой подход поможет.
В тесной .NET интеграции мне проще будет писать extended процедуры. Кроме того они больше не будут такими "опасными".
Поэтому "некие" .NET программисты и предпочтут MS.

QA, кстати, у вас, вообще, не будет.
11 ноя 05, 17:20    [2061467]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

Gluk (Kazan) wrote:
> locky
>
> скажем, даже не 5-10%, а куда меньше... и за сервер это, увы, не
> вынесешь, потому как юзается дла восстановления баз.
>
>
>
> Мои соболезнования :( (с)
Сам нэ хачу!
зы база просто большая, ресторится приходится из rar-архива, вот и
пишем-с помалеху...
--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 17:38    [2061538]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Gluk (Kazan)
Member

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

Сам нэ хачу!
зы база просто большая, ресторится приходится из rar-архива, вот и
пишем-с помалеху...


Не знаю как у вас в MS SQL, но в Oracle ситуация restore относится к категории "Снявши голову по волосам не плачут". Не так сложно работать с zip-ом через java, но где гарантия, что сам этот механизм будет работать коль скоро занадобился restore ???

P.S. RMAN рулит
P.P.S. а потом можно и поджать ежели че
P.P.P.S. а можно и налету, ососбливо на Unix

Всех с тяпницей
11 ноя 05, 17:58    [2061617]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
Gluk (Kazan)
Не знаю как у вас в MS SQL, но в Oracle ситуация restore относится к категории "Снявши голову по волосам не плачут".
Боюсь и MSSQL и Oracle здесь одинаковы. И все эти проблемы решают по разному.
У нас два раза в неделю снимается backup со всех баз и в неделю на 5GB набегает. Куда это добро девать, если не архивировать, DVD-ROM-ов не напасешся. Пока все в одном job-е выполняется.
11 ноя 05, 18:10    [2061658]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

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

Gluk (Kazan) wrote:
> Не знаю как у вас в MS SQL, но в Oracle ситуация restore относится к
> категории "Снявши голову по волосам не плачут". Не так сложно работать с
Вы про чо? про рестор базы при аварии? не, я про базы, которые я в
оффисе восстанавливаю, девелоперские копии. Если база, скажем, 50
гектар, то надоть найти 50 под бэкап и 50 под саму базу, а если из рара
(который пакует где-то в 9-12%) то надо 50+50*0.12=56 гиг, 44 гига
экономия. Да и по времени из рара быстрее восстанавливается.

> zip-ом через java, но где гарантия, что сам этот механизм будет работать
> коль скоро занадобился restore ???
А зип такое и не возьмет, вроде... там ить до 2 гиг ограничение, вроде?

>
> Всех с тяпницей
И Вас туда же.

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

Posted via ActualForum NNTP Server 1.3

11 ноя 05, 19:18    [2061838]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
AAron
2с127
Меня собственно маркетинговые лозунги MS мало интересуют. Пусть кричат, если хочется.


Речь шла не о мелкософте, а о том, что начальство в приказном порядке скажет все писать на .НЕТ-е. Например из тех соображений, что начальство считает, что .НЕТ оно знает, а ТСКЛ - нет. Воспринимайте это как шутку.



Dooma
c127
ИМХО серверная часть удобнее пишется на специально созданном языке сервера, типа PL/SQL
Та часть, которая непосредсвенно DML -несомненно. Так что не волнуйтесь про nested loop.


Совершенно не переживаю nested loop. А при чем тут оно?


Dooma

Тем не менее, например, у меня есть н-ное количество ф-ций которые я точно переведу на .NET. Например ф-ция для печати перевода суммы в словесное представление куда гармоничнее будет выглядеть на C#, да и работать будет быстрее.


То что Вы что-то там переведете на .НЕТ, к сожалению, не означает, что это и в самом деле наилучшее решение. Это что, именно та часть приложения, где ему не хватает производительности? Зачем его оптимизировать по скорости? Я бы их может на С написал, а может и не трогал бы вообще, от ситуации зависит. Но право Ваше.

А почему Вы решили, что они будут работать быстрее? Вы знаете как .НЕТ код встраивается в сервер? Так расскажите. Я, например, не знаю, мне будет интересно послушать.

Dooma
c127
Это мелкософту так бы хотелось. Но на самом деле .НЕТ сопрягается без проблем со всем у кого есть .НЕТ драйвер, так что при выборе сервера лучше использовать более существенные соображения. Дешевле обойдется.
Да нет, это вам бы так не хотелось, но благодаря MS .NET все же лучще сопрягается с Yukon. Да и дешевле обойдется тот же Yukon, и уж тем более в обслуживании.


Это, типа, апрельские тезисы? Доказательно. С цифрами, диаграммами и цитатами. Сразу видно специалиста.

Я не утверждал, что будет дороже, но откуда Вы знаете, что будет дешевле? Вы живьем-то хоть юкон видели, построили на нем хоть одно работающее приложение, или все больше по информации с мелкософтовских сайтов? Так почему Вы решили, что он будет дешевле вообще и в обслуживании в чатсности? И кого он будет дешевле, постгреСКЛ-я с файербердом? Вряд ли.

Dooma
А если имеются в виду расказы про то, как MSSQL не "потянет", а оракл "потянет", то приберегите их для своей бабушки :)


К чему это? Мы вроде обсуждаем полезность интеграции .НЕТ-а в СКЛ сервер. Что, оракл стал поддерживать .НЕТ и на нем тоже работает быстрее МССКЛ-я? Вроде я такого нигде не говорил.

Dooma
Разговор был про разницу в .NET интеграции. А не про что-то другое. Сами в сторону не уводите.


Во-во, и я о том же.

Dooma

В тесной .NET интеграции мне проще будет писать extended процедуры. Кроме того они больше не будут такими "опасными".
Поэтому "некие" .NET программисты и предпочтут MS.

QA, кстати, у вас, вообще, не будет.


Что такое "extended процедуры"? Я подозреваю что Вы зачем-то так называете сохраненки. А почему они опасны? По крайней мере почему написанные на .НЕТ-е они будут безопанее чем на ТСКЛ-е? Если я правильно понял идеологию интегрирования .НЕТ-а в СКЛ сервер, то .НЕТ-овские как раз получаются опаснее, поскольку там СКЛ запросы проверяются во время исполнения, а не во время компиляции, как в ТСКЛ-е:
SqlCommand cmd = SqlContext.GetCommand();
cmd.CommandText = "select intcolumn from tbl";
SqlDataReader r = cmd.ExecuteReader();
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=143322&pg=4&hl=execute#1171756
12 ноя 05, 01:43    [2062612]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
c127
Совершенно не переживаю nested loop. А при чем тут оно?
Это ответ на чью-то шутку выше: "хех. а как же уникальная возможность написать свой собственный вариант nested loops ;)?"

c127
А почему Вы решили, что они будут работать быстрее? Вы знаете как .НЕТ код встраивается в сервер? Так расскажите. Я, например, не знаю, мне будет интересно послушать.
Почитайте сами MSDN и узнаете что куда встраивается.

c127
Это, типа, апрельские тезисы? Доказательно. С цифрами, диаграммами и цитатами. Сразу видно специалиста. ... Так почему Вы решили, что он будет дешевле вообще и в обслуживании в чатсности? И кого он будет дешевле, постгреСКЛ-я с файербердом? Вряд ли.
Когда вы заявляете "Дешевле будет", вы почему-то не приводите ни каких цифр и графиков, но требуете их от меня. Почему же я должен суетится. А по поводу обслуживания, посмотрите средние уровни зарлат DBA на Оракл и на MSSQL. При этом MSSQL справляется с этими же задачами "на ура". Как в рекламе спрашивается: "Если нет разницы, зачем платить больше?" :)

c127
Что такое "extended процедуры"? Я подозреваю что Вы зачем-то так называете сохраненки. А почему они опасны? По крайней мере почему написанные на .НЕТ-е они будут безопанее чем на ТСКЛ-е? Если я правильно понял идеологию интегрирования .НЕТ-а в СКЛ сервер, то .НЕТ-овские как раз получаются опаснее, поскольку там СКЛ запросы проверяются во время исполнения, а не во время компиляции, как в ТСКЛ-е:
Это внешние процедуры "external procedures" в ваших понятиях. Так что вы мимо кассы.
12 ноя 05, 12:36    [2062891]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Хм. Залез я тут посмотреть, что творится в этой теме, и привлекла мое внимание следующая цитата:

yukon2005
XML Support

XML indexes for improved performance
1)Yes 2)No(Text and Functional indexes only)


В связи с этим два вопроса:

1. Правильно ли я понимаю, что с точки зрения микрософта Oracle не умеет индексировать XML?

2. Кстати, в Yukon появилась возможность создания собственных индексов или так и нет?
12 ноя 05, 22:31    [2063337]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
Dooma
c127
Совершенно не переживаю nested loop. А при чем тут оно?
Это ответ на чью-то шутку выше: "хех. а как же уникальная возможность написать свой собственный вариант nested loops ;)?"


Шутка тоже моя?

Dooma

c127
А почему Вы решили, что они будут работать быстрее? Вы знаете как .НЕТ код встраивается в сервер? Так расскажите. Я, например, не знаю, мне будет интересно послушать.
Почитайте сами MSDN и узнаете что куда встраивается.


Вот такая ситуация получается. Вы что-то утверждаете, причем в совершенно безапеляционной форме, а как только Вас просят хоть как-то это обосновать, то Вы отправляете к МСДН, причем без конкретных ссылок. Нет проблем, тут уже был такой Андрей Леонидович, тоже любил подобные аргументы, типа найдите в интернете, найдите в моих предыдущих постах.


Dooma

c127
Это, типа, апрельские тезисы? Доказательно. С цифрами, диаграммами и цитатами. Сразу видно специалиста. ... Так почему Вы решили, что он будет дешевле вообще и в обслуживании в чатсности? И кого он будет дешевле, постгреСКЛ-я с файербердом? Вряд ли.
Когда вы заявляете "Дешевле будет", вы почему-то не приводите ни каких цифр и графиков, но требуете их от меня.


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

Поясняю. Тут утверждается, что все СКЛ сервера неплохо интегрируются с .НЕТ-ом. И поэтому если при выборе СКЛ сервера использовать не соображения интеграции с .НЕТ-ом, с которой и так проблем нет, а более существенные, то такое решение обойдется дешевле.

Так вот тут даже теоретически спорить можно ТОЛЬКО о том, что либо в сопряжении .НЕТ-а с другими СКЛ серверами есть большие проблемы (а их нет), либо что .НЕТ является самым-самым существенным фактором, причем с очень большим отрывом. Что очевидно неверно. А практически вообще спорить не о чем, и так ясно, что .НЕТ самым главным фактором быть может, максимум одним из факторов. Даже Ваши коллеги пытались доказать Вам, что .НЕТ существенным при работе с СКЛ сервером не является.

К тому же тут нигде не сказано, что по более существенным соображениям не выиграет МССКЛ сервер.


Dooma
Почему же я должен суетится.


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


Dooma

А по поводу обслуживания, посмотрите средние уровни зарлат DBA на Оракл и на MSSQL. При этом MSSQL справляется с этими же задачами "на ура". Как в рекламе спрашивается: "Если нет разницы, зачем платить больше?" :)


А с это каких пор стоимость обслуживания системы определяется исключительно зарплатой ДБА? Есть программисты, они тоже обслуживают систему, стоимость СКЛ сервера, он тоже может обслуживаться, например техсапортом производителя, стоимость ОС, железа и куча других вещей. Еще может сыграть роль такой фактор как количество этих самых ДБА. Чтоб было понятнее: 10 ДБА по 50 тыс в год стоят больше чем 5 ДБА по 75 тыс. в год. 75>50, а в результате затрат меньше.

Так что величина зарплаты сама по себе не аргумент. Другие мысли есть?


Dooma

c127
Что такое "extended процедуры"? Я подозреваю что Вы зачем-то так называете сохраненки. А почему они опасны? По крайней мере почему написанные на .НЕТ-е они будут безопанее чем на ТСКЛ-е? Если я правильно понял идеологию интегрирования .НЕТ-а в СКЛ сервер, то .НЕТ-овские как раз получаются опаснее, поскольку там СКЛ запросы проверяются во время исполнения, а не во время компиляции, как в ТСКЛ-е:
Это внешние процедуры "external procedures" в ваших понятиях. Так что вы мимо кассы.


Да, действительно, ошибся. Все время забываю что имею дело со сторонником мелкософта, т.е. с человеком который пользвется уникальной, нигде больше не встречающейся терминологией, и другой не знает. К Вашему сведению в некоторых СКЛ серверах нет разницы между сохраненками и внешними процедурами, например в файерберде и ДБ2.

Вы что, так часто использовали внешниме процедуры, что их безопастность Вас так беспокоит? Скорее всего вообще ни разу. Я, например, только тестировал, на живой базе не использовал никогда по причине ненадобности. Так что их безопастность и мне, и скорее всего Вам тоже, по барабану.

А Почему на .НЕТ-е они "больше не будут такими опасными"? А какими опасными они были, до сих пор?
13 ноя 05, 08:39    [2063625]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить