Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 32 33 34 35 36 [37] 38 39 40 41 .. 54   вперед  Ctrl
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
FreemanZAV
Все это можно высказать и покороче - "если чего-то нет в mssql, значит это в 99% случаев никому не нужно "


Отчего же, кому нужно, тот использует try...catch, если нет простой возможности при любой ошибке откатить транзакцию и прервать выполнение бача.
22 окт 13, 13:27    [15014253]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
Капитан очевидность на проводе
То что работает хорошо для 1000 фактов в секунду - будет хорошо работать и для 1 факта.
А вот обратное в общем случае неверно.
Это верно, но создать и поддерживать identity для небольшой системы - дешевле :)
Нефига ты не кэп :)
22 окт 13, 13:27    [15014257]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
sphinx_mv
Если Вы умудряетесь вставить вызов неотлаженной процедуры в 100500 мест и не можете найти в каком из них она все-таки падает - ну, и кто Вам после этого персональный доктор?!

Отлаженность процедуры - понятие довольно бессмысленное. Большинство интересных ошибок происходит не из-за "ошибки в процедуре", а из-за "неудачного совмещения концепций, заложенных во взаимодействующие сущности". При этом, допустим, одна процедура отлажена три года назад, другая - два года назад, схема их взаимодействия переделана год назад, а подходящие для демонстрации проблемы данные пришли сегодня.
22 окт 13, 13:33    [15014331]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Infernal V. Raven
Это верно, но создать и поддерживать identity для небольшой системы - дешевле :)
Нефига ты не кэп :)


А если это несколько серверов СУБД с Peer-To-Peer репликацией, то разнести на них диапазоны этого самого identity.
22 окт 13, 13:33    [15014335]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
Капитан очевидность на проводе
Infernal V. Raven
пропущено...
Опа. Поделитесь травой букварями.


О боже, какой сказочный дол наивный парень! А раскинуть мозгОм самому невдосуг? Ну ок, поясним на пальцах.
У тебя приложение, вставляет по 500-1000 фактов в секунду. Для окончательного понимания - счетчик показов рекламы, к примеру.

Рассматриваем время реакции на вставку факта и временные затраты серверов (приложения и базы данных).

Вариант первый - приложение само ведет у себя счОтчик и просто сразу прописывает ID в нужном INSERT и в связанных дочерних записях. Одно обращение к серверу - тупо приказать записать все данные в одном PL/SQL блоке.

Вариант второй - приложение сначала делает вставку в сервер, чисто чтоб получить значение ID, потом еще раз должно сходить, уже дочерние записи вставить - итого имеем минимум два обращения на сервер, в режиме "ну ты там БД сервер думай, я пока покурю, от нефиг делать, у меня времени навалом"
Вообще-то есть ещё вариант третий --- приложение дёргает хранимку, которая и ID получит, и дочерние записи вставит, и понаделает при необходимости ещё кучу всякого, и всё это без IPC посреди транзакции. И вариант четвёртый --- веб сервер в самой СУБД, так что хранимка сама делает всю рутину, и только в случае какой-нибудь экзотики дёргает внешнюю логику на hosted language.
22 окт 13, 13:37    [15014377]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Infernal V. Raven
Оракл - долгое время не имел identity column

Есть некая тонкая разница. Когда "после появления фичи" апологет начинает не менее бурно кричать "а у нас теперь есть и это круто", то всё в общем ясно. Если же про identity column.... если в смысле например mssql - то есть немодифицируемые и с неразделяемыми значениями, если мне не изменяет память - то я до сих пор предпочитаю, чтобы таких не было. А если нормальные - так не помню, чтобы кто-то из "апологетов оракла" говорил "нафиг не нужно". Всегда говорили "ну да, лучше бы без триггеров, но и так неплохо".
22 окт 13, 13:39    [15014407]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

Капитан очевидность на проводе
это дополнительный трафик - чтоб сходить на сервер
спросить результат - нужны дополнительные обмены пакетов

Это у какого такого сервера нужны дополнительные round-trip-ы чтобы получить результат
процедуры?

Posted via ActualForum NNTP Server 1.5

22 окт 13, 13:54    [15014590]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
softwarer
sphinx_mv
Если Вы умудряетесь вставить вызов неотлаженной процедуры в 100500 мест и не можете найти в каком из них она все-таки падает - ну, и кто Вам после этого персональный доктор?!

Отлаженность процедуры - понятие довольно бессмысленное.
"Не может быть!" (с)
Процедура должна правильно работать при правильных входных параметрах и в четко оговоренных условиях - техзадание и отладка/тестирование в помощь.
softwarer
Большинство интересных ошибок происходит не из-за "ошибки в процедуре", а из-за "неудачного совмещения концепций, заложенных во взаимодействующие сущности". При этом, допустим, одна процедура отлажена три года назад, другая - два года назад, схема их взаимодействия переделана год назад, а подходящие для демонстрации проблемы данные пришли сегодня.
И что? Процедура с ошибкой уже не может никому рассказать, в какой ситуации она "упала"? Не смешно...
Если эта ситуация раньше не предполагалась - тоже не смертельно: дописать и оттестировать (включая регрессию).
22 окт 13, 13:55    [15014605]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
sphinx_mv
Процедура должна правильно работать при правильных входных параметрах и в четко оговоренных условиях - техзадание и отладка/тестирование в помощь.
будете спорить с тем что с наличием стэка отлаживать удобнее?
если да - то я просто Вам завидую
когда ты чего-то разрабатываешь и оно валится непонятно где в местах, к которым ты отношения не имеешь - ну как без стэка разобраться?
22 окт 13, 14:54    [15015088]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
чччД
Guest
У меня вот сосед дабаггером в Delphi не пользуется. Хоть кол на голове теши.
Какие там ему стеки вызовов.
22 окт 13, 14:56    [15015106]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
sphinx_mv
Процедура должна правильно работать при правильных входных параметрах

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

sphinx_mv
И что? Процедура с ошибкой уже не может никому рассказать, в какой ситуации она "упала"?

Может. Для этого в том числе и нужен стек вызовов. Скажем, пример из моей практики:

  • Процедура падала посреди ночи, потому, что в некоем поле некоей строки таблицы было значение "ноль". Ну вернее не то чтобы падала... выглядело это так: вечером диспетчер назначил исполнителя на завтрашнюю заявку, утром люди приходят на работу - а исполнитель не назначен.
  • Как оно туда попадало - ну очень интересный вопрос
  • К моменту разбора его там не было потому как rollback

  • Вот здесь "программист без стека" сядет медитировать над хрустальным шаром. Собственно, они так две недели и сидели, пока я не пришёл и не рассказал, как зафиксировать стек. С помощью стека наутро же стало ясно, что:

  • Значение попадало в строку в результате работы некоего добавленного относительно недавно триггера денормализации
  • Который дёргался потому, что производилась крайне некорректная операция update-а записи с id = 0 (там была такая тупая система, согласно которой каждая таблица должна была содержать нулевую строку, а foreign key = 0 трактовался как "нет данных")
  • Операция update-а проводилась потому, что эта строчка приезжала по репликации
  • Посреди ночи потому, что update шёл в так называемых "отложенных" данных, которые для снижения дневной нагрузки откладывались на ночь
  • Строчка приезжала по репликации потому, что в некоей операции со смыслом "отослать все данные по бизнес-объекту" не стояло ограничения на id <> 0
  • Сама операция дёргалась руками, причём скорее как аварийная, в основном в случае, когда сотрудника переводили из офиса в офиса.

    sphinx_mv
    Не смешно...

    Да, не смешно. Жизненно. И пока не поразбирал руками ситуации на практике, можно сколько угодно теоретизировать на тему регрессий и спецификаций. Вон, собственно, выше сказка на тему "работа трёх отлаженных процедур".
  • 22 окт 13, 15:20    [15015297]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    SergSuper
    sphinx_mv
    Процедура должна правильно работать при правильных входных параметрах и в четко оговоренных условиях - техзадание и отладка/тестирование в помощь.
    будете спорить с тем что с наличием стэка отлаживать удобнее?
    Когда код "цветасто-кустисто-развесисто-ветвистый", возможно, встроенная функция получения стека вызовов кому-нибудь и как-нибудь поможет - но это очень не факт...
    Куда проще пересмотреть структуру приложения в направлении более простых взаимосвязей - тогда и ошибки будет проще искать, и с сопровождением проблем будет меньше.
    SergSuper
    если да - то я просто Вам завидую
    Не надо завидовать: просто у меня свои "плюшки" (и "заморочки"), у Вас свои.
    SergSuper
    когда ты чего-то разрабатываешь и оно валится непонятно где в местах, к которым ты отношения не имеешь - ну как без стэка разобраться?
    Когда разработчик "слегка не понимает", что у него в системе происходит - это критерий серьезного превышения уровня сложности проекта над уровнем квалификации разработчика. Возможности получения стека вызовов тут, как бы, не очень-то полезна...

    И к вопросу о "местах, к которым не имеешь отношения". Всегда есть кто-то, кто к этим местам отношение имеет - хоть прямое, хоть косвенное.
    22 окт 13, 15:48    [15015543]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    softwarer
    sphinx_mv
    Процедура должна правильно работать при правильных входных параметрах

    Процедура должна правильно работать при любых входных параметрах. Всё прочее - бомба, которая рванёт в том самом "через два года в отлаженной процедуре".
    Нет. Правильная работа гарантируется только при правильных наборах параметров, котрые описываются в тех.задании. Если процедура "не знает" какие параметры "правильные" - это организационная, а не техническая проблема. Другими словами - бардак.
    softwarer
    sphinx_mv
    И что? Процедура с ошибкой уже не может никому рассказать, в какой ситуации она "упала"?

    Может. Для этого в том числе и нужен стек вызовов. Скажем, пример из моей практики:

  • Процедура падала посреди ночи, потому, что в некоем поле некоей строки таблицы было значение "ноль". Ну вернее не то чтобы падала... выглядело это так: вечером диспетчер назначил исполнителя на завтрашнюю заявку, утром люди приходят на работу - а исполнитель не назначен.
  • Как оно туда попадало - ну очень интересный вопрос
  • К моменту разбора его там не было потому как rollback
  • Rollback без диагностики для автоматических процессов - моветон. Нужно его сделать - вот пусть автомат и пишет почему...
    У меня в абсолютно аналогичных ситуациях а) в журналах фиксируется полная диагностика проблемы и б) на мыло и по смс приходит автоматическое сообщение о проблеме и в чем она проявилась... Что я делаю не так?
    softwarer
    sphinx_mv
    Не смешно...

    Да, не смешно. Жизненно. И пока не поразбирал руками ситуации на практике, можно сколько угодно теоретизировать на тему регрессий и спецификаций. Вон, собственно, выше сказка на тему "работа трёх отлаженных процедур".
    Не убедительно.
    Это все жалобы на проблемы в плохо отлаженного технологического процесса. Кто должен этот процесс отладить подсказать? :)
    22 окт 13, 16:10    [15015749]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    iv_an_ru
    Member

    Откуда: Новосибирск
    Сообщений: 20368
    sphinx_mv
    Когда разработчик "слегка не понимает", что у него в системе происходит - это критерий серьезного превышения уровня сложности проекта над уровнем квалификации разработчика. Возможности получения стека вызовов тут, как бы, не очень-то полезна...
    Ну как сказать. Когда я смотрю на очередную клиентскую аппликуху со стороны техподдержки вендора, я никогда не знаю, что там происходит, я её вижу сразу два раза в жизни: первый и последний. И не мне судить об уровне квалификации разработчика --- 1) это не мой разработчик, и 2) это запросто может быть лучший разработчик среди знающих ту предметку на нужном уровне. И вот тут возможность быстро увидеть цепочку может оказатсья решающей --- хотя бы сразу видно, в "наших" хранимках проблема (скажем, невнятная диагностика об ошибках в параметрах) или в клиентских.
    22 окт 13, 16:23    [15015876]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67463
    Блог
    sphinx_mv
    Нет. Правильная работа гарантируется только при правильных наборах параметров,

    Если при неправильных наборах параметрах "негарантированный" модуль разносит систему - это, мягко говоря, не бардак. Это, очень мягко говоря, халтура. Модуль должен правильно работать при любых данных (то есть давать результат тогда, когда это возможно, сколь возможно доходчиво рассказывать, почему он не дал результат тогда, когда его дать невозможно, и не портить данных никогда).

    sphinx_mv
    Rollback без диагностики для автоматических процессов - моветон.

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

    sphinx_mv
    Нужно его сделать - вот пусть автомат и пишет почему... У меня в абсолютно аналогичных ситуациях а) в журналах фиксируется полная диагностика проблемы

    Ага, то есть "в той ситуации" Вам ночью на мыло приходит сообщение примерно с той информацией, которую я изложил, и при этом без использования стека вызовов. Я всё правильно понял?

    sphinx_mv
    Что я делаю не так?

    Хм. Предпочту пока не отвечать на этот вопрос :)

    sphinx_mv
    Не убедительно.

    Не сомневаюсь. Я вот давеча дочку убеждал, что мультики она смотрит в дерьмовом качестве. Вывел на монитор слева картинку с её мультика, справа - тот же кадр с hdtv скриншота, говорю - видишь разницу? Она произнесла замечательную фразу: "Папа, ты споришь с убеждённым человеком", но ушла, задумавшись. И это максимум того, на что можно рассчитывать с 99% людей.
    22 окт 13, 16:42    [15016082]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    iv_an_ru
    sphinx_mv
    Когда разработчик "слегка не понимает", что у него в системе происходит - это критерий серьезного превышения уровня сложности проекта над уровнем квалификации разработчика. Возможности получения стека вызовов тут, как бы, не очень-то полезна...
    Ну как сказать. Когда я смотрю на очередную клиентскую аппликуху со стороны техподдержки вендора, я никогда не знаю, что там происходит, я её вижу сразу два раза в жизни: первый и последний.
    Мне чуть по-сложнее - приходится не только "видеть сразу два раза", но и работать и не только с "посторонним" (иногда и "потусторонним") программным обеспечением, но и с весьма внушительным списком оборудования, с которого собирается информация... Меняются версии, меняются протоколы, меняется апи... Все как у всех.
    И, что естествено, без тестов на полигоне (не в рабочем окружении) ни одно изменение не запускается в работу.
    iv_an_ru
    И не мне судить об уровне квалификации разработчика
    Мне тоже на самом деле нет дела до уровня квалификации разработчиков. Мне есть дело до правильной работы программного обеспечения - любой его части.
    Правильность работы определяется соответствием функционала требованиям, заложенным в спецификацию/техзадание/техстандарт/итдитп.
    iv_an_ru
    --- 1) это не мой разработчик, и 2) это запросто может быть лучший разработчик среди знающих ту предметку на нужном уровне. И вот тут возможность быстро увидеть цепочку может оказатсья решающей --- хотя бы сразу видно, в "наших" хранимках проблема (скажем, невнятная диагностика об ошибках в параметрах) или в клиентских.
    Если на вход "моей" части поступают данные, не соответствующие спецификации - какой "стек" мне поможет это посмотреть? Подсказка - никакой. Пинать в копчик буду (и пинаю) вендора - независимо от того, какой его разработчик и какой квалификации написал его "продукт", и совершенно независимо, его ли это вообще разработчик был... Пинать "собственного", пусть и "наиболее знающего" разработчика тоже буду. Но наличие стека вызовов-то здесь при чем? Чтобы узнать, сколько процедур дергает какой-то метод? Ну, я это и так знаю по таблице взаимозависимостей...
    22 окт 13, 17:06    [15016330]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    iv_an_ru
    Member

    Откуда: Новосибирск
    Сообщений: 20368
    sphinx_mv,

    Ну, когда к каждому сообщению об ошибке прикрепляется весь стек вызовов функций со всеми значениями аргументов --- это намного лучше, чем лаконичное "Can not convert VARCHAR '15 mg doxylamine succinate' to DATETIME".
    22 окт 13, 17:16    [15016381]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67463
    Блог
    sphinx_mv
    Правильность работы определяется соответствием функционала требованиям, заложенным в спецификацию/техзадание/техстандарт/итдитп.

    Правильность работы определяется соответствием ожиданиям (заказчиков, пользователей итп). А спецификации-техзадания - всего лишь способ (к сожалению, не всегда верно) эти ожидания формализовать.
    22 окт 13, 17:23    [15016446]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    iv_an_ru
    Member

    Откуда: Новосибирск
    Сообщений: 20368
    softwarer
    sphinx_mv
    Правильность работы определяется соответствием функционала требованиям, заложенным в спецификацию/техзадание/техстандарт/итдитп.

    Правильность работы определяется соответствием ожиданиям (заказчиков, пользователей итп). А спецификации-техзадания - всего лишь способ (к сожалению, не всегда верно) эти ожидания формализовать.
    +1 Майерс --- наше всё.
    22 окт 13, 17:27    [15016476]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    sphinx_mv
    я это и так знаю по таблице взаимозависимостей...

    Ну да, а грязную работу - угадывать из какой ветки развесистого графа взаимозависимостей
    пришли данные, которые процедура не смогла переварить - Вы гордо оставляете "разработчику
    вендора". Конечно, проблемы же нет пока оно стреляет не в вашу сторону.

    Posted via ActualForum NNTP Server 1.5

    22 окт 13, 17:54    [15016624]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    kdv
    Member

    Откуда: iBase.ru
    Сообщений: 30253
    Капитан очевидность на проводе
    Черпать технические знания из новостей - это просто +стопиццот. Глубина уважухи к личности kdv начинает зашкаливать все немыслимые пределы. Этот человек ерунды не посоветует, ни ни, как можно?!

    Дубина, я не работаю с Ораклом, не консультирую по нему, ясно же сказал. И про Оракл тут ничего не говорю. В отличие от тебя, несущего тут ахинею про ФБ. Похоже, что тебя действительно жмёт.
    22 окт 13, 18:01    [15016663]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    softwarer
    sphinx_mv
    Нет. Правильная работа гарантируется только при правильных наборах параметров,

    Если при неправильных наборах параметрах "негарантированный" модуль разносит систему - это, мягко говоря, не бардак. Это, очень мягко говоря, халтура. Модуль должен правильно работать при любых данных (то есть давать результат тогда, когда это возможно, сколь возможно доходчиво рассказывать, почему он не дал результат тогда, когда его дать невозможно, и не портить данных никогда).
    Способов исключительной обработки неправильных входных данных много больше одного.
    softwarer
    sphinx_mv
    Rollback без диагностики для автоматических процессов - моветон.

    И что Вы собрались фиксировать? Каждую деталь каждой процедуры (которая завтра, как оказывается, может быть вызвана "из автоматических процессов"?
    У меня каждый последовательный этап обработки набора данных фиксируется изменением его состояния. Соответственно, в любой момент я могу прервать или восстановить обработку с точки останова в соответствии с текущим состоянием.
    softwarer
    Собственно репликация - уже неизбежный "автоматический процесс".
    А давайте Вы не будете мне рассказывать, как автоматически сливать и обрабатывать данные, приходящие из разных источников. Ок? :)
    softwarer
    sphinx_mv
    Нужно его сделать - вот пусть автомат и пишет почему... У меня в абсолютно аналогичных ситуациях а) в журналах фиксируется полная диагностика проблемы

    Ага, то есть "в той ситуации" Вам ночью на мыло приходит сообщение примерно с той информацией, которую я изложил, и при этом без использования стека вызовов. Я всё правильно понял?
    Контроль входных параметров выполняется в начале процедуры - и это самый верхний интересующий уровень вызовов в стеке. Ниже него совсем нет ничего, выше него нет ничего реально полезного... Получить описание состояния системы (список параметров и их значений, данные из исключительной ситуации, номер строки процедуры/функции, вызвавшей ошибку) более чем достаточно для любой диагностики.

    К тому же (если действительно припрет) обеспечить передачу ошибки в вызывающие процедуры, чтобы построить "стек вызовов", проблемы (на самом деле) не представляет. Это тот самый "неуловимый Джо", котрый никому он не нужен, и которого никто не ловит.
    22 окт 13, 18:15    [15016719]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67463
    Блог
    sphinx_mv
    Способов исключительной обработки неправильных входных данных много больше одного.

    Глубокомысленная вода там, где, видимо, нечего сказать по делу. Если попытаться соотнести это высказывание с предыдущими, получается, что "работать неправильно" - это такой изысканный "способ исключительной обработки неправильных входных данных". Забавно, забавно.

    sphinx_mv
    У меня каждый последовательный этап обработки набора данных фиксируется изменением его состояния. Соответственно, в любой момент я могу прервать или восстановить обработку с точки останова в соответствии с текущим состоянием.

    Ага, уже показались пять золотых. Если копнуть ещё немного, окажется, что "наборы данных" у Вас в общем не поражают разнообразием и довольно стабильны (потому как зависят от аппаратуры), процедур их обработки, соответственно, тоже сравнительно немного, и именно поэтому путей вызова немного, зависимости легко прослеживаются и стек вызовов, в общем, не нужен. Угадал?

    sphinx_mv
    А давайте Вы не будете мне рассказывать, как автоматически сливать и обрабатывать данные, приходящие из разных источников. Ок? :)

    Вторая глубокомысленная фраза, не имеющая отношения к тому, на что отвечает.

    sphinx_mv
    Контроль входных параметров выполняется в начале процедуры

    (Зевая) Сфинкс, не приходило ли Вам в голову, что одним из входных параметров процедуры являются данные базы - каждое поле каждой строки использованных таблиц?

    sphinx_mv
    (список параметров и их значений, данные из исключительной ситуации, номер строки процедуры/функции, вызвавшей ошибку)

    О, уже появился номер строки. Интересно, откуда :)

    sphinx_mv
    более чем достаточно для любой диагностики.

    Да-да. Примените это к приведённому мной примеру, посмеёмся вместе. Итак, дано: таблица, по ночам в некоторых записях некоторое (имевшее значение) поле сбрасывается в 0, что является непосредственной причиной наблюдаемых проблем. Рассказывайте, как будете диагностировать настоящую причину.

    sphinx_mv
    К тому же (если действительно припрет) обеспечить передачу ошибки в вызывающие процедуры, чтобы построить "стек вызовов", проблемы (на самом деле) не представляет.

    Не представляет. Если не считать того, что довольно геморройно кодировать. Я понимаю, что Вы ориентируетесь на свои десять ХП, но их бывает и тысяча. В той системе, о которой идёт речь, только пакетов было порядка сотни, как мне помнится. И если бы я посоветовал им перекомпилить весь хранимый код, аккуратно при этом вставив в каждую хранимку "вход в хп такую-то", "выход из хп такой-то", "второй-третий-четвёртый return-ы из хп такой-то", "возбуждение исключения в хп такой-то", "необработанное исключение, приводящее к выводу из хп такой-то".... В общем, я весьма благодарен вендору, который избавил меня от такой работы.

    sphinx_mv
    Это тот самый "неуловимый Джо", котрый никому он не нужен, и которого никто не ловит.

    Столь яркая любовь к словам типа "никто" и "никогда" имхо свойственна людям лет в двенадцать.
    22 окт 13, 19:31    [15017000]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    sphinx_mv
    И к вопросу о "местах, к которым не имеешь отношения". Всегда есть кто-то, кто к этим местам отношение имеет - хоть прямое, хоть косвенное.
    "Добро пожаловать в реальный мир!"(С)
    Где Вы и окажитесь этим "кто-то"

    softwarer
    Я понимаю, что Вы ориентируетесь на свои десять ХП, но их бывает и тысяча. В той системе, о которой идёт речь, только пакетов было порядка сотни, как мне помнится.

    я и Вам завидую - у меня их 50000))
    22 окт 13, 19:40    [15017029]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    SergSuper
    softwarer
    Я понимаю, что Вы ориентируетесь на свои десять ХП, но их бывает и тысяча. В той системе, о которой идёт речь, только пакетов было порядка сотни, как мне помнится.

    я и Вам завидую - у меня их 50000))

    50000 чего? Пакетов? ХП?
    22 окт 13, 19:51    [15017060]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 32 33 34 35 36 [37] 38 39 40 41 .. 54   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить