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

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

Gluk (Kazan) wrote:
> locky
>
> непрофессионально.. работать надо с тем, с чем надо (эк меня!). Тем паче
> радоваться, что иметь будете опыт в 2-х областях, а не в одной,
> следовательно будете иметь более высокую ликвидность.
>
> Не надо судить о профессионализме тех, кого никогда в глаза не видел,
> ладно ? Что касается опыта, я его приобрету хочу я того или нет,
> последнее печалит больше всего :(
>
Договорились, не будем, договорились. Хотя, даже не так, я допишу ИМХО,
так будет политкорректно.

> Обижаться на меня тоже не надо. Я уже четыре с лишним месяца без
> выходных трахаюсь с этим гребанным .Net-ом в частности, а в отпуск не
> ходил уже лет 10. Немножко устал от произведений M$, а Unix в той
> конторе где я сейчас работаю не в ходу
ДА ПРИЧЕМ ТУТ точка-сеть к SQL??? Ну причем тут оно!!!! Нет, ну
объясните старику!!!! Вы трахаетесь с дотнет, а хаете сиквел - хде логика???
Вы не пробовали не трахать продукты MS, а любить их? глядишь, ответят
взаимностью.

зы 10 лет... я 12, и чо?

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

Posted via ActualForum NNTP Server 1.3

7 окт 05, 18:12    [1949955]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Петя Какашкин
Member [заблокирован]

Откуда: Засранец из сортира
Сообщений: 8
tygra
А как Юкон подошел к финишу - все, копец.
Чуете, что смерть ораклова пришла?

Блин, не успел опять до сортира добежать - прочитал и от страха обосрался...
Пошел штаны стирать.

С полным приветом, Петя
7 окт 05, 18:56    [1950093]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Gluk (Kazan)

Разумеется это будет быстрее (и скорее всего глючнее). Вам пытались сказать другое. Скорость исполнения PL/SQL НЕ КРИТИЧНА в большинстве задач. Реально перевод PL/SQL кода в native (кроме головняков) дает прирост производительности 3-5%. Исходя из убожества TSQL можно предположить что в вашем случае прирост производительности будет процентов 10.
Стоит ли овчинка выделки ???

Никто (из дееспособных) не собирается использовать .NET сборки для замены всего кода t-sql. Работа с данными все равно будет производиться на t-sql, ибо это по определению будет быстрее.
.NET предлагают использовать для вычислительных и пр. задач, где написаная таким образом функция будет эффективнее sql кода. И задач таких, не так-уж и много. Но встречаются.
ЛП

Ну знаете ли, так и Visual Basic (и офисный VBA), даже без компиляции в native-код, с одним лишь P-Code - получается компилятором, .

Это я в курсе, моя первая реальная программа была по обработке данных на VBA. Видили-бы вы, сколько она работает, если в файле оказывается более пары тысяч строк... до сих пор хожу краснею...
Gluk (Kazan)

видеть не хочу это угребище, но спрашивать меня никто не будет

я-бы вот например, нашел другую работу. Это (особенно в Москве) сложностей не представляет. Какой смысл напрягаться на работе, она радость должна приносить...
locky

другое дело, насколько вырастут затраты на
реализацию нужного функционала, насколько упадёт скорость разработки и
насколько снизится надежность

вот я про это и говорил. Если реализация чего-либо начинает представлять проблему - фича должна быть реализована в языке. И вообще, я вроде не утверждал, что t-sql язык моей мечты, и давайте его не развивайте. Я говорил про то, что реализовывать фичность надо с умом, а не тащить все подряд, как Плюшкин.
А вот насчет надежности и производительности - тут не все так-уж однозначно. К примеру, используемый мной алгоритм обработки деревьев работает ничуть не медленнее оракловского connect to prior (буквально до миллисекунд). С надежностью тоже проблем небыло.
А вот если пойти по другому пути, и реализовать алгоритм Джо Селко, так он сделает и мой алгоритм и оракловую фичу одной левой. Так что, думайте, господа...
locky

Покупают - значит нравится? не, не показатель... я вот курю не слишком
шикарные сигареты. а хочется курить шикарные... денег жалко...

Дык тут вступает в действие посторонний фактор - ваша жадность. На качество это не влияет...
locky

зы телек без ДУ-шки купите? Нет? А что, так сложно оторвать задницу от
дивана? Не, просто пустячок, а приятно...

Ни фига себе - пустячок. Одно из самых главных достоинств современных телевизоров.
ASCRUS

проголосовали против его включения, чтобы не долбаться с кроссплатформенностью потом.

К счастью, нам такая проблема не грозит. Можем спокойно использовать, и не бояться, что под какой-нибудь осью придется трахаться...
7 окт 05, 21:07    [1950353]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

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

Очень странное мнение. К какому же спрашивается счастью - если одноплатформенность снижает конкуретноспособность ПО и круг клиентов ?

Кстати слово "трахаться", так же как и выражение "танцевать с бубном", "матиться на ограничения" и прочее на моей памяти уже почти стерты временем ... с тех пор, как я перестал работать с MSSQL. Уже прошло 2 года и я не помню, чтобы хоть раз столкнулся с какой то проблемой, которая не решалась бы средствами СУБД, ограничениями, которые бы ограничивали мою свободу и странностями, которые бы заставляли меня искать обходные пути. В MSSQL-же этого было предостаточно и вряд ли тут кто то сможет с этим спорить. Ко всему прочему, я не могу сказать, что до сих пор знаю полностью весь потенциал текущей СУБД и не потому, что она сложная в изучении, как Оракл например. Просто слишком большой функциональный обхват различных направлений и ко всему прочему резвое непрерывное развитие даже с выходящими фиксами и паками. Здесь тоже MSSQL ничем не сможет похвастаться. Мы можем спокойно сравнить список расширения функциональности одной подверсии со всеми расширениями всех паков MSSQL2000. У меня только по одной подверсии список обгонит все то, что MSSQL добавил во всех паках с 2000-ого года. Я не спорю, что при желании все проблемы решаемы, но очень удобно и выгодно, когда платформа не имеет ограничений и своей функциональностью позволяет делать любые вещи, а не плясать с бубном, трахаться или уводить код на клиента или 3-и звенья.

P.S. Пишу надо думать не с байды, опыт работы с MSSQL имел и до сих пор имею на крупных проектах, так что как говорится могу действительно сравнивать. Проверить достаточно легко - просто попытаться на нашем форуме поискать вопросы, которые наиболее часто задаются на форуме MSSQL в связи с ограничениями, проблемами и прочим. Если отбросить из условий поиска СУБД ASE, то окажется, что таких вопросов у нас просто нет, так как нет и таких проблем. Поиск конечно на SQL.RU не ахти, но при желании понять достоинства и недостатки любой интересующей СУБД можно, особенно когда форум средней активности. Чем я кстати и пользуюсь, чтобы иметь представления о конкурирующих платформах, а заодно не отставать от жизни, чтобы не получилось упереться носом в что то одно и проглазеть другие технологии и решения, то есть стать узкопрофильным специалистом.
7 окт 05, 22:52    [1950544]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Gluk (Kazan)
автор
T-SQL все-таки интерпретатор

А .Net шо нет ??? Не делайте мне смешно.
Кстати 9 Oracle УМЕЕТ компилять PL/SQL в native-код только никому это нах не нужно. Прежде чем ходить по тем-же граблям, Microsoft следовало внимательнее изучить опыт тех кто УЖЕ ходил по ним раньше

aZm
а давайте не будем приписывать мне то, чего я не говорил? я выразился предельно четко - решать при помощи нета (.Net) задачи обработки данных на сервере - бред. это делать на tsql нужно, который худо бедно под это заточен. где вы увидели призыв вынести логику из базы, ы?

по поводу того, что .Net компилятор и поэтому будет работать быстрее чем интерпретируемый tsql - спасибо, порадовали :) 5 минут смеха заменяет чего то очччч хорошее :) .Net, как и родственная ему по идеологии жаба - интерпретаторы по определению :) ибо требуют для выполнения свою виртуальную машину/фреймворк.

ваши слова лишний раз говорят о вашей недалекости, уж извините такие мои слова. Вы не потрудились проверить мои мысли, а просто предпочли быстренько их отвергнуть. Тесты, реальные тесты, говорят о том что .Net иногда оказывается очень полезен. T-SQL идеально подходит для DML операций, но вот для циклов, сложных мат.расчетов, регулярных выражений он подходит гораздо меньше чем .Net.
Поэтому если такие вещи заменить .Net объектами, то производительность существенно возрастает (CLR находится с SQL Server 2005 в одном процессе, в отличие от реализаций интеграции Oracle и DB2).

aZm
а вообще, убеждать когото, кто полагает, что производительность сервера прямо зависит от того, как быстро отработается хранимый код(если не численные методы применям ), а не от того, как быстро движок базы вернет искомые данные - мартышкин труд, пока сам не столкнется с большими объемами данных, его никто не убедит.
Вы здесь новенький? Не поленитесь посмотреть мои предыдущие посты на этом сайте прежде чем делать голословные заявления.

Gluk (Kazan)
C .Net нам приходится работать уже сейчас. На вкус говно. С Юконом тоже придется работать с вероятностью 90% и перспектива эта воодушевления не вызывает :( Какие обиды, клиенты падки на маркетинговые уловки и нам приходится жрать говно. Мы в одной лодке, просто вам оно нравится, мне нет.
В отличие от вас мы ничего подобного не едим, нам не с чем сравнивать.

Gluk (Kazan)
Все профессионально и совсем не по детски, к сожалению
профессионально - это более-менее объективно, а у вас этого нет совсем, к сожалению, потому что есть некоторые ваши посты из которых видно что вы мужик неглупый.

Gluk (Kazan)
P.S. Тенденции в развитии Oracle меня тоже не воодушевлют, но это отдельная тема, что касается MS SQL, лучше-бы он оставался честным блокировочником
опять мимо, вот вы говорите голословно, а я делаю реальные проекты на SQL2005, и в некоторых из них версионность (особенно RCSI) реально увеличивают производительность решения.
8 окт 05, 00:10    [1950678]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
vadiminfo
Member

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

не потому, что она сложная в изучении, как Оракл например

Не очень то и ясно что имеется в виду под сложностью изучения Оракла.
Налабать на нем простую БД, по моему, может кому тока не лень. И лабают. Посмотрите форум Оракла. Там полно парней задают наивные вопросы. Т.е. не давно начали и уже шо-то слепили. Я то вижу многих кто работает. Там и студенты, которые смутно представляют что-такое БД и все.

Изучить многие базовые нюансы, которые имеют значение не так часто - так наверное и в других СУБД надо возиться. Просто там может не быть чего-то полезного. Так здесь можно не изучать и будет как там (типа нету).

Изучить все что есть, фичи, не базовые особенно - другое дело. Наверное, не знает никто. Да и смысла нет - они могут меняться в новых версиях.
Мастерство в не в том, чтобы все знать, а в том чтобы уметь найти нужную фичу, када нужна. Наверное и язык С в полном объеме, тем более С++ в плане всех библиотек или еще чего не так много народу знает. Главное, чтобы эта фича там оказалась. А во всем остальном, по моему, ничего сложного. Зачем запугивать желющих перейти на него?
8 окт 05, 00:14    [1950688]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
segun
Member

Откуда: Москва
Сообщений: 504
ASCRUS
автор
К счастью, нам такая проблема не грозит. Можем спокойно использовать, и не бояться, что под какой-нибудь осью придется трахаться...

Очень странное мнение. К какому же спрашивается счастью - если одноплатформенность снижает конкуретноспособность ПО и круг клиентов ?
Одноплатформенность уже перестала быть сдерживающим фактором. По крайней мере в умах заказчиков.
И еще - много чего можно решить средствами СУБД, и Oracle долго шел по этому пути, а все почему? Потому что у Oracle нет своей платформы. Вот и приходится все, нужное и ненужное, помещать в СУБД.
8 окт 05, 00:27    [1950707]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ЛП
Guest
2 StalkerS
StalkerS
ЛП

Ну знаете ли, так и Visual Basic (и офисный VBA), даже без компиляции в native-код, с одним лишь P-Code - получается компилятором, .

Это я в курсе, моя первая реальная программа была по обработке данных на VBA. Видили-бы вы, сколько она работает, если в файле оказывается более пары тысяч строк... до сих пор хожу краснею...

А хотите я Вам ник подарю - "лох позорный"?
Тока сначала Джуджа попрошу, чтоб он буквачки к нижнему регистру привел.
8 окт 05, 02:55    [1950731]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

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

Очень странное мнение. К какому же спрашивается счастью - если одноплатформенность снижает конкуретноспособность ПО и круг клиентов ?

Во первых, то, что сейчас делаю я - проект для внутреннего пользования предприятия, никуда его продавать никто не будет. Поэтому нас меньше всего волнует круг клиентов.
Для тех-же случаев, где идет разработка на сторону - конкурентноспособность в большей степени зависит от подвешенности языка маркетологов, а не от реальных способностей системы. Проблемы маркетинга меня совершенно не интересуют, но вообще, если подумать, хороший продавец втюхает что угодно. Ведь даже если вы, с огромным опытом разработчик, говорите, что "я не могу сказать, что до сих пор знаю полностью весь потенциал текущей СУБД", ожидать чего-то от конечных пользователей...
Зато для меня, как разработчика, проблем-то и в самом деле меньше. И для меня это плюс.
ASCRUS

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

Как-то сложно поверить, что ваша ASA "не имеет ограничений и своей функциональностью позволяет делать любые вещи". Как и Оракл и mssql. Все системы развиваются, и я всего-то утверждал, что при этом развитии должен учитываться нужный функционал, а не все подряд. Помимо деревянных фичей, могу дать другой пример - триггеры before. Если-бы в них была реальная потребность - были-бы реализованы. Видимо, такой потребности нет, во всяком случае я еще на такие на натыкался.
vadiminfo

Налабать на нем простую БД, по моему, может кому тока не лень. И лабают.

да, и получаются у них замечательные произведения искусства. Вспомните ваши первые проекты...

2 ЛП
Нифига не понял, что вы хотели сказать, может мне для этого тоже надо напиться ? :)
8 окт 05, 08:47    [1950786]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

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

не потому, что она сложная в изучении, как Оракл например

Не очень то и ясно что имеется в виду под сложностью изучения Оракла.
Налабать на нем простую БД, по моему, может кому тока не лень. И лабают. Посмотрите форум Оракла. Там полно парней задают наивные вопросы. Т.е. не давно начали и уже шо-то слепили. Я то вижу многих кто работает. Там и студенты, которые смутно представляют что-такое БД и все.

Вспоминать студентов, лабающих на SQL курсовые смысла нет ... да им все равно на чем лабать - на Оракле или MySQL.

vadiminfo
Изучить многие базовые нюансы, которые имеют значение не так часто - так наверное и в других СУБД надо возиться. Просто там может не быть чего-то полезного. Так здесь можно не изучать и будет как там (типа нету).

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

vadiminfo
Изучить все что есть, фичи, не базовые особенно - другое дело. Наверное, не знает никто. Да и смысла нет - они могут меняться в новых версиях.
Мастерство в не в том, чтобы все знать, а в том чтобы уметь найти нужную фичу, када нужна. Наверное и язык С в полном объеме, тем более С++ в плане всех библиотек или еще чего не так много народу знает. Главное, чтобы эта фича там оказалась. А во всем остальном, по моему, ничего сложного. Зачем запугивать желющих перейти на него?

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

P.S. Я лично более чем уверен, что Вы vadiminfo например, после месяца изучения и работы на моей платформе будете знать и уметь не меньше, чем сейчас знаете и умеете на Oracle и даже гораздо больше (имеется ввиду не просто знать, а уметь использовать). Я же за месяц на Oracle разве что выучу в достаточном обьеме проектирование, PL/SQL, динамический SQL и более менее принципы работы версионника и правильную организацию транзакций. Все остальные ньюансы, а так же администрирование, работу на различных ОС и прочее ... на это у меня уйдет явно больше года постоянной работы с Oracle. Ну ... а писать запросы к существующим БД - это мы и сейчас все можем вне зависимости от используемого сервера. Разница очевидна.
8 окт 05, 09:12    [1950792]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

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

Во первых, то, что сейчас делаю я - проект для внутреннего пользования предприятия, никуда его продавать никто не будет. Поэтому нас меньше всего волнует круг клиентов.

Тогда не нужно рассказывать, что это никому не нужно, если это Вам не нужно.

StalkerS

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

Когда человек говорит, что "Я знаю все" - это меня очень настораживает. Поэтому я и не знаю все - и не потому, что это сложно или гемморно - просто то, что я не знаю, не использовалось мной в работе по текущий момент и зная теорию я не могу сказать, что я это знаю (например я не знаю UltraLite - построение проектов для КПК - просто не было проектов).

StalkerS

ASCRUS

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

Как-то сложно поверить, что ваша ASA "не имеет ограничений и своей функциональностью позволяет делать любые вещи". Как и Оракл и mssql. Все системы развиваются, и я всего-то утверждал, что при этом развитии должен учитываться нужный функционал, а не все подряд. Помимо деревянных фичей, могу дать другой пример - триггеры before. Если-бы в них была реальная потребность - были-бы реализованы. Видимо, такой потребности нет, во всяком случае я еще на такие на натыкался.

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

P.S. Я более чем уверен, что BEFORE триггера Вам не понадобились и всю логику проверок Вы выносите в AFTER триггера, что достаточно замечательно с точки зрения производительности: сжирания ресурсов на блокировки, лишней записи в лог и БД и дальнейших операций откатов после того, как триггер обнаружил несоотвествия и дал откат. Вам не кажется, что проверить, запретить или даже изменить нужные поля обрабатываемой записи, причем без DML, легче ДО, чем ПОСЛЕ физической записи в БД и именно для этого и существуют BEFORE триггера ?
8 окт 05, 09:57    [1950807]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

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

Тогда не нужно рассказывать, что это никому не нужно, если это Вам не нужно.

Это где я такое рассказывал ?
ASCRUS

Поэтому я и не знаю все - и не потому, что это сложно или гемморно

Я не говорил, что знать надо все, я говорил, что фича кроссплатформенности при продаже - проблема продавцов, а не разработчиков...
ASCRUS

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

Зачем так утрировать ? Или вы все-таки утверждаете, что ASA не имеет ограничений и позволяет делать любые вещи ? А самолетом она управлять умеет ? :) (кстати, вы - разработчик этой системы ?)
ASCRUS

P.S. Я более чем уверен, что BEFORE триггера Вам не понадобились и всю логику проверок Вы выносите в AFTER триггера, что достаточно замечательно с точки зрения производительности: сжирания ресурсов на блокировки, лишней записи в лог и БД и дальнейших операций откатов после того, как триггер обнаружил несоотвествия и дал откат. Вам не кажется, что проверить, запретить или даже изменить нужные поля обрабатываемой записи, причем без DML, легче ДО, чем ПОСЛЕ физической записи в БД и именно для этого и существуют BEFORE триггера ?

на случай, если заботит лишняя запись в лог и лишние откаты - есть instead of триггера. Мне это не кажется тем узким местом в производительности, которое надо обязательно расшивать.
Вы-же сами сейчас сказали - " без прикручивания лишних непонятно кому нужных фич". Я с этим полностью согласен...
8 окт 05, 11:21    [1950874]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Зачем так утрировать ? Или вы все-таки утверждаете, что ASA не имеет ограничений и позволяет делать любые вещи ? А самолетом она управлять умеет ? :) (кстати, вы - разработчик этой системы ?)

Я не ее разработчик, ее разработчик - компания Watcom, впоследствие купленная и вошедшая в состав Sybase. А утверждаю я исходя из личного опыта построения проектов, что ASA действительно не имеет тех или иных ограничений по сравнению с MSSQL, которые навскидку могу перечислить:
1. Размер страницы не фиксированный (1,2,4,8,16,32 кб).
2. Автоинкремент может автоматически вести в разрезах по каждому установленному коду БД, что необходимо для репликации, без каких либо манипуляций ручками.
3. Есть функция получения нового инкремента, что делает очень похожим инкремент ASA с сиквенсами и облегчает жизнь клиентским приложениям.
4. Максимальный размер varchar не 8 кб, а 32 кб.
5. Тип Text может хранить до 2гб и к нему можно обращаться внутри языка хранимых процедур так же, как и обычным varchar.
6. Динамический SQL не имеет ограничений на размер исполняемого скрипта (т.е. до 2 гб), при выполнении соблюдатся все права вызвавшей его сессии, его использование в ХП не наносит какого либо ущерба производительности.
7. Нет ограничений на уровень вложенности вызовов хранимых процедур.
8. При компиляции запросов или ХП их план поддерживается в кэше и корректируется эвристическим анализатором, а значит не требуется их перекомпиляция.
9. Автоматическое коррелирование статистики на SELECT и создание на возросшие по обьему таблицы, там где ее не было приводит к тому, что не требуется ее перекомпиляция.
10. Наличие BEFORE триггеров дает возможность легко снизить нагрузки на проверку или даже модицикацию при записи полей.
11. Нет ограничений на UDF, они полностью по возможностям равны ХП.
12. Есть возможность использовать SELECT FROM StoredProcedures(), где так же нет ограничений на ХП, в отличие от табличных функций MSSQL
13. Есть глобальные временные таблицы, описание которых хранится в БД, выглядит она как обычная таблица, однако для каждой сессии данные будут свои (где по сравнению ##Времянки выглядят убого).
14. Есть поддержка NOT TRANSACTIONAL локальных и глобальных временных таблиц, что приводит к увеличению скорости времянок.
15. Есть поддержка оператора INSERT ON EXISTS SKIP/UPDATE/RESTRICT - аналог Ораклевого MERGE, здорово сокращающего код и упращяющего логику.
16. Есть поддержка событийной модели, позволяющей на языке хранимых процедур описывать реакцию на системные события, по шедулеру или ручному их вызову, которые после вызова работают как автономные приватные сессии сервера, что позволяет внутри одной сессии в нужных случаях еще создавать параллелизм (есть даже команды синхронизиции между сессиями на уровне языка ХП). Так же событийная модель позволяет например перехватывать подключения и отключения сессий, что дает прекрасные возможности по организации собственных проверок на право подключения сессии (например пользователь не имеет право подключаться дважды, кол-во подключений ограничено, на пользователя висит временный бан в специальной своей табличке запретов подключений и прочее), инициализации и предустановки для сессии своих глобальных переменных (вместо того, чтобы каждый раз к табличке конфигурации своей обращаться), так же при отключении удаление по коду сессии записей, что дает возможность легкой организации блокировок документов на своем уровне и прочие интересные и важные вещи, без которых БД не будет автономна и независима от клиентской части.
17. Есть исключения, атомарные блоки и прочие приятные, облегчающие код вещи.
18. Другая реализация принципов кластерного ключа исключает проблемы, которые есть с ним у MSSQL
19. Другая реализация архитектуры блокировок позволяет не задумываться о проблемам с ними - все блокировки для проектировщика всегда выглядят как исключительно как ROW-LEVEL, без экскалаций, есть возможность наложения табличных блокировок.
20. Есть встроенный веб-сервер и полноценный XML парсер, что позволяет на уровне сервера средствами языка ХП организовывать собственные HTML/XML веб-сервисы или же обращаться к сторонним, описывая их в БД внешними URL хранимыми процедурами и далее вызывая их, как обычные ХП. Для HTML поддерживаются GET/POST методы, таким образом прямо на сервере на ХП можно организовать небольшую веб-клиентскую часть под браузер для собственных нужд (та же администраторская консоль).
21. Другая архитектура оптимизатора и другие алгоритмы оптимизации действительно позволяют ASA на больших обьемах данных и особенно аггрегированных запросах более быстрое их выполнение, с более скромным потреблением ресурсов, что приводит к более большому числу обслуживаемых сессий.
22. Наличие поддержки полноценного OLAP в SQL по стандарту 2003 (в принципе полный аналог OLAP в Oracle) и поддержка специализированных алгоритмов оптимизации позволяет практически моментально выполнять аналитические запросы, которые на обычном SQL заняли бы часы.
23. Другая архитектура сервера, где каждая БД - это и схема и данные и пользователи и настройки БД, без БД типа Master или TempDB позволяет элементарно переносить БД с сервера на сервер элементарным копированием файлов, что облегчает тиражирование, инсталяцию, обслуживание и распостранение уже подготовленных БД - с юзерами, правами, настройками и прочим.
24. Рекурсивные запросы и опция отложенных проверок нужных FK до COMMIT позволяет элементарно строить и обрабатывать деревья. Причем для рекурсивных запросов опять же существуют специализированные алгоритмы их обработки в запросах, что особенно не маловажно при использовании рекурсивного запроса как подзапроса.
25. Про 2 вида оффлайн репликаций - по журналу и гетерогенные с другими СУБД я вообще молчу, тут ASA просто вне конкуренции по их мощности, простоте управления и надежности работы. Это целый другой список.
26. Про UltraLite версию для КПК и кучу софта под управления удаленными СУБД на КПК я тоже молчу - тоже целый список.
27. Более развитые визуальные утилиты - есть полноценный дебаггер, с возможностью точек останова, просмотра локальных и глобальных переменных (кстати в ASA и они есть, можно создавать свои настоящие глобальные сессионные переменные), даже выполнения запросов во время отладки и просмотра их плана выполнения (приятно при отладке триггера написать SELECT * FROM Inserted и посмотреть самому, что он будет обрабатывать). Так же есть профайлер ХП, которые позволяет мониторить их выполнение, видеть сколько раз кто вызывался, какое время было затрачено на выполнение и даже построчно в ХП посмотреть на каждую строку кода и время выполнения, что немаловажно для отлова критических мест системы и мониторинга эффективности работы кода.
Это все перечислено навскидку, список этот наверное и не займет одну треть, что есть в ASA и всегда мне не хватало в MSSQL - перечислил я его просто чтобы показать, что в отличие от MSSQL у ASA функциональности гораздо больше, ограничений нет, архитектура легче и ньюансов гораздо меньше, что в проектировании, что в администрировании (которое сводится в основном к тому, чтобы написать на нужные случае жизни события, которые и будут автоматически вызываться, решать возникающие проблемы или уведомлять по почте нужных администраторов, которая так же прекрасно поддерживается в ASA через SMTP или MS Exchange). Я не спорю, что без всего этого можно жить - но согласитесь приятнее жить с этим, чем без этого. Как никак - очень влияет на время разработки и отладки проектов, облегчает их дальнейшее сопровождение, а так же легче поиск и обучение специалистов, где любой СУБД-шник быстро вьедет в принципы и начнет работать, без каких либо больших усилий и спотыкания об "ньюансы".
8 окт 05, 14:32    [1951074]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Просьба сюда глянуть. Это побочнпая ветвь
https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=223999&pg=-1#1951143
8 окт 05, 15:23    [1951144]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Yo!!
Guest
Cat2
Просьба сюда глянуть. Это побочнпая ветвь
https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=223999&pg=-1#1951143


было уже
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=148020
8 окт 05, 15:37    [1951157]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Надо будет в FAQ что ли перенести все пункты и ссылочки просто давать. А то получается одно и то же пишу и каждый раз по новой спрашивают и не верят :)
8 окт 05, 16:48    [1951195]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Yo!!
Guest
ASCRUS
Надо будет в FAQ что ли перенести все пункты и ссылочки просто давать. А то получается одно и то же пишу и каждый раз по новой спрашивают и не верят :)

у меня была мысль сделать нормальные разделы по каждой фиче на wiki.ru, интузиазизма аж на пару статеек хватило :)
8 окт 05, 16:58    [1951208]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
ASCRUS
ASA действительно не имеет тех или иных ограничений по сравнению с MSSQL, которые навскидку могу перечислить
Список впечатляющий.


ASCRUS
1. Размер страницы не фиксированный (1,2,4,8,16,32 кб).

Т.е., в одной БД могут использоваться страницы разного размера ? Хотя, скорее, все-таки в одной БД могут использоваться фиксированные страницы возможным размером из перечисленного диапазона. И как часто Вы его изменяете для БД ? От чего зависит выбор ? Какой реальный выигрыш ? Или просто есть, а у MSSQL нет ?

Кстати, пункт 4 наверняка тоже зависит от размера страницы.
ASCRUS
2. Автоинкремент может автоматически вести в разрезах по каждому установленному коду БД, что необходимо для репликации, без каких либо манипуляций ручками.
Не понял фразы.
ASCRUS
3. Есть функция получения нового инкремента, что делает очень похожим инкремент ASA с сиквенсами и облегчает жизнь клиентским приложениям.
Польза весьма сомнительна. Используйте SCOPE_IDENTITY()
ASCRUS
4. Максимальный размер varchar не 8 кб, а 32 кб.
Непринципиально. Что не поместилось в 8к, с таким же успехом может не поместится в 32к, а у адептов еще одной СУБД появиться повод сказать, а вот у нас целых 64к. Либо есть ограничение сверху, либо нет.
ASCRUS
5. Тип Text может хранить до 2гб и к нему можно обращаться внутри языка хранимых процедур так же, как и обычным varchar.
За каким лешим обрабатывать текст на сервере баз данных ? У него других проблем нет ? Впрочем, если считать, что этот класс задач органично присущ СУБД, то MSSQL, безусловно, в отстающих.
ASCRUS
6. Динамический SQL не имеет ограничений на размер исполняемого скрипта (т.е. до 2 гб),
Впечатляет, как понимаю, вопрос о целесообразности выполнения скрипта таких размеров не вызывает сомнений ? Так как в MSSQL всего 2 МБ, в 1000 раз меньше, то безусловный минус...
ASCRUS
при выполнении соблюдатся все права вызвавшей его сессии
Не понял, в чем здесь отличие от MSSQL ?
ASCRUS
, его использование в ХП не наносит какого либо ущерба производительности.
Угу, даже на время компиляции. Свежо предание...
ASCRUS
7. Нет ограничений на уровень вложенности вызовов хранимых процедур.
Действительно важно, 32 уровней может не хватить. Правда больше 5 уровней не имел ни в одном проекте, но это уже минус мне, как разработчику.
ASCRUS
8. При компиляции запросов или ХП их план поддерживается в кэше и корректируется эвристическим анализатором, а значит не требуется их перекомпиляция.
В MSSQL, конечно же, план в кэше не "держится" :)
ASCRUS
9. Автоматическое коррелирование статистики на SELECT и создание на возросшие по обьему таблицы, там где ее не было приводит к тому, что не требуется ее перекомпиляция.
Не понял, если несложно, то расшифруйте...
ASCRUS
10. Наличие BEFORE триггеров дает возможность легко снизить нагрузки на проверку или даже модицикацию при записи полей.
Спорный вопрос, поэлементная обработка всегда медленнее, чем работа наборами записей.
ASCRUS
11. Нет ограничений на UDF, они полностью по возможностям равны ХП.
Тогда зачем их вообще различать ? Делать как в C, никаких процедур, только функции. На понятийном уровне они всегда различались тем, что одни что-то меняют, другие вычисляют.
ASCRUS
12. Есть возможность использовать SELECT FROM StoredProcedures(), где так же нет ограничений на ХП, в отличие от табличных функций MSSQL
Здесь почти соглашусь, вполне можно было автоматически полученные данные сбрасывать во временную таблицу или табличную переменную. Хотя есть масса нюансов, при которых такое решение может доставить хлопот. В основном, проблемы с производительностью. Как альтернативное решение не помешало бы.
ASCRUS
13. Есть глобальные временные таблицы, описание которых хранится в БД, выглядит она как обычная таблица, однако для каждой сессии данные будут свои (где по сравнению ##Времянки выглядят убого).

Ну да, сделать постоянную таблицу и определить доступ к ней через view действительно трудно.
ASCRUS
14. Есть поддержка NOT TRANSACTIONAL локальных и глобальных временных таблиц, что приводит к увеличению скорости времянок.
Табличные переменные для локальных, глобальные в жизни ни разу не потребовались, это, насколько понимаю, backward compatibility от предка Sybase.
ASCRUS
15. Есть поддержка оператора INSERT ON EXISTS SKIP/UPDATE/RESTRICT - аналог Ораклевого MERGE, здорово сокращающего код и упращяющего логику.
Скорее соглашусь, хотя сильный скачок в сторону от стандарта.
ASCRUS
16. Есть поддержка событийной модели, позволяющей на языке хранимых процедур описывать реакцию на системные события, по шедулеру или ручному их вызову, которые после вызова работают как автономные приватные сессии сервера, что позволяет внутри одной сессии в нужных случаях еще создавать параллелизм (есть даже команды синхронизиции между сессиями на уровне языка ХП). Так же событийная модель позволяет например перехватывать подключения и отключения сессий, что дает прекрасные возможности по организации собственных проверок на право подключения сессии (например пользователь не имеет право подключаться дважды, кол-во подключений ограничено, на пользователя висит временный бан в специальной своей табличке запретов подключений и прочее), инициализации и предустановки для сессии своих глобальных переменных (вместо того, чтобы каждый раз к табличке конфигурации своей обращаться), так же при отключении удаление по коду сессии записей, что дает возможность легкой организации блокировок документов на своем уровне и прочие интересные и важные вещи, без которых БД не будет автономна и независима от клиентской части.
Событийная модель, отчасти реализуема и сейчас через механизм alert-ов, слава Богу, пока ни разу не понадобиласть. Согласен, многого из упомянутого, касательно сессий хотелось бы, впрочем в 2К5 обещались. Возможность пользовательских блокировок в MSSQL есть и сейчас. "прочие интересные и важные вещи" возможно тоже нужны, но непонятно о чем речь.
ASCRUS
17. Есть исключения, атомарные блоки и прочие приятные, облегчающие код вещи.
Исключений не хватает, а вот про "атомарные блоки и прочие приятные" вещи сказать ничего не могу, возможно, тоже не хватает.
ASCRUS
18. Другая реализация принципов кластерного ключа исключает проблемы, которые есть с ним у MSSQL
Упс, в двух словах, please, про проблемы одного и решения другого, или наоборот...
ASCRUS
19. Другая реализация архитектуры блокировок позволяет не задумываться о проблемам с ними - все блокировки для проектировщика всегда выглядят как исключительно как ROW-LEVEL, без экскалаций, есть возможность наложения табличных блокировок.
Что не видит разработчик, не значит, что их не существует там, где он их не видит. Неубедительно. Чем принципиально отличается реализация архитектуры блокировок ASA от реализации MSSQL ?
ASCRUS
20. Есть встроенный веб-сервер и полноценный XML парсер, что позволяет на уровне сервера средствами языка ХП организовывать собственные HTML/XML веб-сервисы или же обращаться к сторонним, описывая их в БД внешними URL хранимыми процедурами и далее вызывая их, как обычные ХП. Для HTML поддерживаются GET/POST методы, таким образом прямо на сервере на ХП можно организовать небольшую веб-клиентскую часть под браузер для собственных нужд (та же администраторская консоль).
Ну да, для СУБД, важнейшая составная часть, а еще с текстовыми файлами напрямую работать, в графических изображениях гамму корректировать, рукописные тексты разбирать...
ASCRUS
21. Другая архитектура оптимизатора и другие алгоритмы оптимизации действительно позволяют ASA на больших обьемах данных и особенно аггрегированных запросах более быстрое их выполнение, с более скромным потреблением ресурсов, что приводит к более большому числу обслуживаемых сессий.
Поэтому он в лидерах на tpc.org ?
ASCRUS
22. Наличие поддержки полноценного OLAP в SQL по стандарту 2003 (в принципе полный аналог OLAP в Oracle) и поддержка специализированных алгоритмов оптимизации позволяет практически моментально выполнять аналитические запросы, которые на обычном SQL заняли бы часы.
Неубедительно, чудес на свете не бывает, где-то прибыло, где-то убыло, либо сервер - OLTP, либо - OLAP. Судя по всему, прямой конкурент Oracle. Какое место на tpc.org ?
ASCRUS
23. Другая архитектура сервера, где каждая БД - это и схема и данные и пользователи и настройки БД, без БД типа Master или TempDB позволяет элементарно переносить БД с сервера на сервер элементарным копированием файлов, что облегчает тиражирование, инсталяцию, обслуживание и распостранение уже подготовленных БД - с юзерами, правами, настройками и прочим.
Перенести БД с одного сервера на другой в MSSQL вообще-то тоже труда не составляет. Похоже Вы давно не делали этого на MSSQL. Чем Вам TempDB не угодила, ума не приложу, Вы ведь ее копировать и тиражировать не собирались ?
ASCRUS
24. Рекурсивные запросы и опция отложенных проверок нужных FK до COMMIT позволяет элементарно строить и обрабатывать деревья. Причем для рекурсивных запросов опять же существуют специализированные алгоритмы их обработки в запросах, что особенно не маловажно при использовании рекурсивного запроса как подзапроса.
РМД, вообще говоря, не расчитана на работу с деревьями, хотя хотелось бы чего-нибудь этакого. По слухам будет в 2К5. По жизни работа с деревьями не вызывала проблем, был волен сам выбирать способ хранения и алгоритмы работы. Не уверен, что работает медленнее, чем если бы была встроенная поддержка.
ASCRUS
25. Про 2 вида оффлайн репликаций - по журналу и гетерогенные с другими СУБД я вообще молчу, тут ASA просто вне конкуренции по их мощности, простоте управления и надежности работы. Это целый другой список.
Тоже молчу, не сталкивался.
ASCRUS
26. Про UltraLite версию для КПК и кучу софта под управления удаленными СУБД на КПК я тоже молчу - тоже целый список.
Продолжаю молчать, хотя помню, что есть какая-то версия CE, не сталкивался...
ASCRUS
27. Более развитые визуальные утилиты - есть полноценный дебаггер, с возможностью точек останова, просмотра локальных и глобальных переменных (кстати в ASA и они есть, можно создавать свои настоящие глобальные сессионные переменные), даже выполнения запросов во время отладки и просмотра их плана выполнения (приятно при отладке триггера написать SELECT * FROM Inserted и посмотреть самому, что он будет обрабатывать). Так же есть профайлер ХП, которые позволяет мониторить их выполнение, видеть сколько раз кто вызывался, какое время было затрачено на выполнение и даже построчно в ХП посмотреть на каждую строку кода и время выполнения, что немаловажно для отлова критических мест системы и мониторинга эффективности работы кода.
Есть дебаггер, есть, правда ни разу не пользовался :) А вот отсутствие глобальных сессионных переменных действительно минус, эмуляция через таблицу отнимает массу времени и сил ;) И профайлер, кстати, тоже в MSSQL есть, как это Вы его не заметили ? И делает он все то же, что Вы описали :)
ASCRUS
Это все перечислено навскидку, список этот наверное и не займет одну треть, что есть в ASA и всегда мне не хватало в MSSQL - перечислил я его просто чтобы показать, что в отличие от MSSQL у ASA функциональности гораздо больше, ограничений нет, архитектура легче и ньюансов гораздо меньше, что в проектировании, что в администрировании (которое сводится в основном к тому, чтобы написать на нужные случае жизни события, которые и будут автоматически вызываться, решать возникающие проблемы или уведомлять по почте нужных администраторов, которая так же прекрасно поддерживается в ASA через SMTP или MS Exchange). Я не спорю, что без всего этого можно жить - но согласитесь приятнее жить с этим, чем без этого. Как никак - очень влияет на время разработки и отладки проектов, облегчает их дальнейшее сопровождение, а так же легче поиск и обучение специалистов, где любой СУБД-шник быстро вьедет в принципы и начнет работать, без каких либо больших усилий и спотыкания об "ньюансы".
Безусловно, по функциональности ASA надо сравнивать с Oracle, а не убогим MSSQL, так как последний писали однозначные дебилы. И такие же дебилы его покупают. Просто ужасно...
8 окт 05, 17:24    [1951233]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
А я и не спорю, что при желании, времени и силах на MSSQL можно сделать нормальный проект. Просто затраты будут больше и БД все равно будет зависеть от чего то внешнего (в Юконе вот еще и C# припаяют). И профайлером и деббагером MSSQL можно оптимизацию и отладку делать, если больше ничего не видел и не с чем сравнить, как можно на самом деле легко и удобно делать. Спорить по каждому пункту можно до тошноты, но делать этого не будем - я привел навскидку список того, что мне больше устраивает в ASA, чем в MSSQL, имея опыт работы с обоими серверами. Вы не видя ASA и не имея опыта работы с ней, считаете, что список этот не критичен. Я соглашаюсь - он не критичен, он удобен.

P.S. Поправочка: функция SCOPE_IDENTITY() возвращает не новый зарезервированный код инкремента, а последний вставленный (замазка @@IDENTITY, который в MSSQL может перебиться от вставки записи внутри триггера в таблицу с другим инкрементом, чего кстати тоже нет в ASA, у которой @@IDENTITY имеет понятие области видимости и производитель не имеет привычки делать заплатки своих огрехов в виде примочек-функций).
8 окт 05, 17:41    [1951239]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
locky
Member

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

2ASCRUS
Слюшай, хвытыт издиваться, у миня от этого язва разыгралась от зависти.
Опять... :-)

ChA wrote:
> 7. Нет ограничений на уровень вложенности вызовов хранимых процедур.
>
> Действительно важно, 32 уровней может не хватить. Правда больше 5
> уровней не имел ни в одном проекте, но это уже минус мне, как разработчику.
> ASCRUS
У меня был рекурсивный разбор дерева вычисления формулы... йопс!
пришлось передлать под стэковый... фиг с ним...
а вот уровень вложенности вызова менеджеров доходил до 29 (это когда
запускает проца закрытия периода, которая запускает формирование
документа, который запускает формирование отчета, который запускает
пароцедуры расчета разных цифр, которые берутся из других отчетов, для
чего зпаускаются другие отчеты, в доме который построил джек).

> 13. Есть глобальные временные таблицы, описание которых хранится в БД,
> выглядит она как обычная таблица, однако для каждой сессии данные будут
> свои (где по сравнению ##Времянки выглядят убого).
>
>
> Ну да, сделать постоянную таблицу и определить доступ к ней через view
> действительно трудно.
> ASCRUS
а таблице можно сделать truncate, а вьюшке с разделением по тому-же SPID
нельзя, в результате чего можем иметь до 30% проигрыша по времени.
Учитывая что если сделать delete то можно нарваться на эскалацию
блокировок и прочие процессы будут курить... а так - у каждого -
абсолютно личная таблица, никто никого не блокирует, удалять данные из
них - просто блеск... кроме того, такие таблички чистятся САМИ при
обрыве коннекта, а при MS SQL приходится чистить их ручками, как после
расчета, так и до (на всякий случай).

> 14. Есть поддержка NOT TRANSACTIONAL локальных и глобальных временных
> таблиц, что приводит к увеличению скорости времянок.
>
> Табличные переменные для локальных, глобальные в жизни ни разу не
> потребовались, это, насколько понимаю, backward compatibility от предка
> Sybase.
> ASCRUS
А вы попробуйте позаливать данные из внешних файлов. или посчитать
большие отчеты с множеством промежуточных данных. там нах не нужны
транзакции, но их, млин, поддерживают... опять таки - проигрышь по
скорости....

> Перенести БД с одного сервера на другой в MSSQL вообще-то тоже труда не
> составляет. Похоже Вы давно не делали этого на MSSQL. Чем Вам TempDB не
> угодила, ума не приложу, Вы ведь ее копировать и тиражировать не
> собирались ?
да потому что она одна на весь сервак!!!! И для простенькой ленивой
задачки, и для высоконагруженной.. вы почитайте, как мелкософт советует
обходить проблемы одновременного доступа к tempdb...



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

Posted via ActualForum NNTP Server 1.3

8 окт 05, 18:40    [1951284]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Добавлю насчет tempdb.
Помимо временных таблиц, SQL Server использует tempdb для хранения данных промежуточных worktable при исполнении запросов. В Юконе - там же будут лежать и версии данных. Таким образом, tempdb может действительно стать узким местом.

Вот интересно будет посмотреть, насколько интенсивно начнет использоваться tempdb, на скольких винтах ее придется делать
8 окт 05, 19:03    [1951294]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
ChA
...Безусловно, по функциональности ASA надо сравнивать с Oracle, а не убогим MSSQL, так как последний писали однозначные дебилы. И такие же дебилы его покупают. Просто ужасно...
В свое время имел некоторый опыт работы с Sybase SQL Anywhere 5.x (3.5 года). Потом, волею судеб пришлось перейти на Oracle (тогда еще 7.3, потом 8.0, сейчас вот на 9i работаю). И полагаю, что для обычных приложений (где нет терабайтов данных) новая ASA практически ничем не уступает Oracle, а по таким параметрам как простота администрирования и репликации существенно превосходит.
А когда немного пришлось заниматься MS SQL 6.5 (надо было переносить серверную часть приложения - ничего не поделаешь, популярный :-( ), матерился через каждые пять минут - и того нет, и этого нет, и так сделать нельзя, функцию в запрос включать нельзя, а триггеры только statement level ;-)
Причем, заметьте, все те возможности, которые перечислил ASCRUS, не в "последней бете", не в "релиз-кандидате" и не в "третьем сервис-паке, который вот-вот выйдет", а в нормальных продуктах, давным-давно выпущеных, документированных, поддерживаемых не только производителем, но и сообществом пользователей, что тоже имеет не последнее значение :-)
8 окт 05, 22:09    [1951415]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
ASCRUS
А я и не спорю, что при желании, времени и силах на MSSQL можно сделать нормальный проект.
А что тут спорить-то ? Насколько мне известно, количество инсталяций MSSQL, по крайней мере, в России, превышает количество таковых от Oracle, и весьма значительнее, от Sybase, в число которых входит не только ASA. И это несмотря на потрясающие "фичи" обоих и гораздо более позднее появление на этом рынке MS. Рынок - показатель успешности компании, а не крутизна ее продуктов или количество фич.

ASCRUS
P.S. Поправочка: функция SCOPE_IDENTITY() возвращает не новый зарезервированный код инкремента, а последний вставленный (замазка @@IDENTITY, который в MSSQL может перебиться от вставки записи внутри триггера в таблицу с другим инкрементом, чего кстати тоже нет в ASA, у которой @@IDENTITY имеет понятие области видимости и производитель не имеет привычки делать заплатки своих огрехов в виде примочек-функций).
Мне не кажется более правильным получать идентификатор до реальной вставки данных, уж извините. Это ведет к тому, что будете добавлять записи только по одной, не задумываясь о необходимости нормального предметного ключа, а не только суррогатного. Но то, что понадобилось добавлять SCOPE_IDENTITY() в пару к @@IDENTITY действительно удивляет, готов с Вами согласиться. Иногда кажется, что в MS больше теоретиков и творцов, чем нормальных программистов. Например, код системных процедур иногда просто вызывает оторопь.

locky
нельзя, в результате чего можем иметь до 30% проигрыша по времени.
Учитывая что если сделать delete то можно нарваться на эскалацию
блокировок и прочие процессы будут курить... а так - у каждого -
абсолютно личная таблица, никто никого не блокирует, удалять данные из
них - просто блеск... кроме того, такие таблички чистятся САМИ при
обрыве коннекта, а при MS SQL приходится чистить их ручками, как после
расчета, так и до (на всякий случай).
30%, если правильно понимаю, взято с потолка, в лучшем случае, на основе частного случая. Делайте кластерный ключ со spid первым полем, и ни с кем конфликтовать не будете. И чистите всегда до, а не после. Впрочем, зачем мне это Вам обьяснять, полагаю, что Вы и сами это знаете. Могу согласиться, что в ASA с этим работать проще, но в то же время не чувствую себя обделенным благами, мне обычно редко чего не хватает, всегда можно сделать самому, слава Богу, есть на это время и желание.
locky
А вы попробуйте позаливать данные из внешних файлов.
BULK оставляет только факт своего выполнения в логе, это-то Вы должны знать
locky
или посчитать большие отчеты с множеством промежуточных данных. там нах не нужны транзакции, но их, млин, поддерживают... опять таки - проигрышь по скорости...
Тут мне сказать нечего, кроме того, что есть OLTP, где отчеты могут носить только простейший характер, и OLAP, где аналитики могут рыться как свиньи в желудях. Разный подход, разная актуальность и точность данных, и подходы к хранению данных - тоже разные. Стремление объединить вполне понятно, но, IMHO, либо танк, либо самолет, либо не то и не другое...
locky
да потому что она одна на весь сервак!!!!
И что ? Ну сделайте больше файлов, разнесите на разные диски, stripping, каналы, контроллеры. Делайте хоть что-нибудь, жаловаться на жизнь все могут. В конце концов убедите начальство, если сами к таким не относитесь, перейти на Oracle или ASA, вот оно счастье и наступит. Хотя у начальства другие приоритеты обычно :)

AAron
В Юконе - там же будут лежать и версии данных. Таким образом, tempdb может действительно стать узким местом.
Когда будет, тогда и посмотрим. Вполне возможно, хотя версионностью пользоваться пока не собираюсь, и не уверен, что она является панацеей от всех бед, как почему-то многие считают. Возможно заблуждаюсь, но и примеров пока не встречал.

PL99
А когда немного пришлось заниматься MS SQL 6.5 (надо было переносить серверную часть приложения - ничего не поделаешь, популярный :-( ), матерился через каждые пять минут - и того нет, и этого нет, и так сделать нельзя, функцию в запрос включать нельзя, а триггеры только statement level ;-)
Точно так же матерился, когда с MS SQL переходил на Informix, и что ? Приспособился, либо работаешь, либо материшься, всегда предпочитал первое. Кстати, функций в 6.5 еще не было, что не так уж сильно и мешало, все зависит от привычки, есть - хорошо, нет - будем думать, что делать. А вообще, IMHO, нормальным MSSQL стал только с 7 версии...
9 окт 05, 01:47    [1951555]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ЛП
Guest
ChA
ASCRUS
А я и не спорю, что при желании, времени и силах на MSSQL можно сделать нормальный проект.
А что тут спорить-то ? Насколько мне известно, количество инсталяций MSSQL, по крайней мере, в России, превышает количество таковых от Oracle, и весьма значительнее, от Sybase, в число которых входит не только ASA. И это несмотря на потрясающие "фичи" обоих и гораздо более позднее появление на этом рынке MS.

Вы тока что хуйню сказали.
Насколько мне известно, количество инсталяций MS Access, по крайней мере в России, превышает количество таковых для Oracle, ASA и MS SQL Server вместе взятых. И это несмотря на потрясающие "фичи" всех трех и гораздо более позднее появление аксеса на рынке БД.

Рынок - показатель успешности компании, а не крутизна ее продуктов или количество фич

Вот-вот. Вам говорят про крутизну продуктов и количество фич - а Вы пытаетесь сползти на рыночную долю.
9 окт 05, 02:11    [1951564]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
yukon2005
Guest
aZm
через ADO ? внутреннее соединение с сервером, так скать)?
А вы смейтесь, смейтесь...
Чтобы бы знали, внутренние механизмы MSSQL уже с mssql2000 работают через OLEDB. В частности Relational Engine и Store Engine - два важнейших компонента общаются через OLEDB (прямо внутри сервера). И это не нисколько не замедляет работу сервера, что говорит о большой производительности этой объектной технологии.
ADO лишь еще одна оболочка вокруг того же OLEDB и вовсе не такая уж тормозная (хотя и помедленее будет). Бывают и явно неудачные ее реализации (например, ADOExpress в Delphi).
Так что ваш смех - всего лишь очередной смех невежды и MS-фоба ;)
9 окт 05, 02:19    [1951568]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить