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

Откуда: St.Petersburg
Сообщений: 1710
Капитан очевидность на проводе
Значение PK должны назначаться приложением, а не базой. Учите уже буквари по архитектуре приложений, не позорьтесь.
Опа. Поделитесь травой букварями.

Претензий к FB никаких нет. За исключением того, что это embeded база данных, целевая аудитория - до пары гигабайт базенки.
Ой ли? Это откуда подчерпнуто?
22 окт 13, 11:07    [15012762]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Капитан очевидность на проводе
Guest
Infernal V. Raven
Капитан очевидность на проводе
Значение PK должны назначаться приложением, а не базой. Учите уже буквари по архитектуре приложений, не позорьтесь.
Опа. Поделитесь травой букварями.


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

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

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

Вариант второй - приложение сначала делает вставку в сервер, чисто чтоб получить значение ID, потом еще раз должно сходить, уже дочерние записи вставить - итого имеем минимум два обращения на сервер, в режиме "ну ты там БД сервер думай, я пока покурю, от нефиг делать, у меня времени навалом"


Дети, вы такие смешные, право. Неужто самим не очевидно прописное?

Infernal V. Raven
Претензий к FB никаких нет. За исключением того, что это embeded база данных, целевая аудитория - до пары гигабайт базенки.
Ой ли? Это откуда подчерпнуто?

Из отсутствия таких вещей, как tablepaces, partitioning, bitmap indexes, star joins, buffer pool management и прочих VLDB ништяков баз данных.

И главное - даже отсутствия факта понимания необходимости оных, у аффторов. Про вещи вроде бекапов и ресторов больших баз данных мы тоже уже все выяснили - ситуация пока "пипец приплыли, в 3.0 обещают починить".
22 окт 13, 11:16    [15012832]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

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

Если так - то согласен. А если 1 факт в минуту? От задачи же ж. Это к слову о том кто "сказочный дол наивный парень!"
22 окт 13, 11:20    [15012876]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
sphinx_mv
FreemanZAV
Насколько я знаю, в MSSQL, например, нельзя до сих пор получить стек вызовов ХП и триггеров - это тоже в какой-то степени мониторинг.
Профайлер?
Выборка нужных событий и фильтр с нужными критериями?
С возможностью выгрузить результат куда угодно (в табличном виде) для любой пост-обработки?


В профайлере очень муторно ловить ошибку, особенно если она сложно воспроизводится. Тот же многими ругаемый FB, при ошибке выдаёт полный стек вызовов, причём этот функционал существует уже лет 8
22 окт 13, 11:26    [15012943]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Капитан очевидность на проводе
Вариант второй - приложение сначала делает вставку в сервер, чисто чтоб получить значение ID, потом еще раз должно сходить


INSERT dbo.SomeTableWithServerSideGeneratedID
OUTPUT INSERTED.ID
VALUES (...);
22 окт 13, 11:30    [15012990]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Infernal V. Raven
Навскидку:
MSSQL - в свое время не имел русского BOL,
Не аргумент - совсем...
Русскоязычной официальной документации нет на многие продукты - и, что характерно, никто от этого еще не умер.
Infernal V. Raven
сиквенсов,
Можно подумать, что до сиквенсов жизни не было...
Infernal V. Raven
аналитических функций.
В свое время такого понятия как "аналитические функции" не существовало. И что?
Infernal V. Raven
Оракл - долгое время не имел identity column
И еще долгое время какого-то особого применения не найдет - даже после тотального перехода на версию сервера, котрый поддерживает эту фичу (аналогично и для сиквенсов в MS SQL).
22 окт 13, 11:33    [15013018]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

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

В профайлере очень муторно ловить ошибку, особенно если она сложно воспроизводится.
Сложно воспроизводимая ошибка еще и усугубленная "тяжелыми последствиями" - повод плотно задуматься над дизайном системы.
FreemanZAV
Тот же многими ругаемый FB, при ошибке выдаёт полный стек вызовов, причём этот функционал существует уже лет 8
Ну, так и в MSSQL (любой версии!) Вам никто не запрещает правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е.
22 окт 13, 11:44    [15013139]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
sphinx_mv
FreemanZAV
пропущено...

В профайлере очень муторно ловить ошибку, особенно если она сложно воспроизводится.
Сложно воспроизводимая ошибка еще и усугубленная "тяжелыми последствиями" - повод плотно задуматься над дизайном системы.
FreemanZAV
Тот же многими ругаемый FB, при ошибке выдаёт полный стек вызовов, причём этот функционал существует уже лет 8
Ну, так и в MSSQL (любой версии!) Вам никто не запрещает правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е.


Это всё верно, но стек всё равно не получить
22 окт 13, 11:50    [15013199]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
sphinx_mv
И что?

Знаешь методику "и че?" http://maltzewa.ru/rekomenduyu/unikalnaya-metodika-resheniya-problem
вот, собственно, и ничо.
Основная мысль была, что флагманы тоже пытаются догонять друг друга и не всегда это у них не происходит быстро.
Фичи я привел навскидку, на самом деле их больше. Про нужность/ненужность уже наломали достаточно копий.
22 окт 13, 11:51    [15013220]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
sphinx_mv
Ну, так и в MSSQL (любой версии!) Вам никто не запрещает правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е.


Кстати, насколько я помню, возможность правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е появилась всего лишь 8 лет назад )
22 окт 13, 11:55    [15013279]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Гость333
Member

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

При этом с базой всегда работает только один экземпляр приложения?
22 окт 13, 12:04    [15013365]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
FreemanZAV
Кстати, насколько я помню, возможность правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е появилась всего лишь 8 лет назад )
Если ты то BEGIN TRY - то да :)
22 окт 13, 12:06    [15013395]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Infernal V. Raven
FreemanZAV
Кстати, насколько я помню, возможность правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е появилась всего лишь 8 лет назад )
Если ты то BEGIN TRY - то да :)


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

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

iv_an_ru
до скольки-то девяток надёжности это так. Скажем, когда "СУБД" работает
только с девяти до пяти на машине одного из сотрудников.

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

Posted via ActualForum NNTP Server 1.5

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

Откуда: СПб
Сообщений: 4507
Капитан очевидность на проводе
О боже, какой сказочный дол наивный парень! А раскинуть мозгОм самому невдосуг? Ну ок, поясним на пальцах.
У тебя приложение, вставляет по 500-1000 фактов в секунду. Для окончательного понимания - счетчик показов рекламы, к примеру.
Рассматриваем время реакции на вставку факта и временные затраты серверов (приложения и базы данных).
Вариант первый - приложение само ведет у себя счОтчик и просто сразу прописывает ID в нужном INSERT и в связанных дочерних записях. Одно обращение к серверу - тупо приказать записать все данные в одном PL/SQL блоке.
Вариант второй - приложение сначала делает вставку в сервер, чисто чтоб получить значение ID, потом еще раз должно сходить, уже дочерние записи вставить - итого имеем минимум два обращения на сервер, в режиме "ну ты там БД сервер думай, я пока покурю, от нефиг делать, у меня времени навалом"
Дети, вы такие смешные, право. Неужто самим не очевидно прописное?
.

А чего вызвать функцию или процедуру на сервере с параметрами, которая сразу вставит данные и возвратит id религия не позволяет... Действительно детский сад, в приложении изобретать свой уникальный id...
22 окт 13, 12:41    [15013766]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

Sergey Orlov
Действительно детский сад, в приложении изобретать свой уникальный
id...

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 1672
FreemanZAV
sphinx_mv
Ну, так и в MSSQL (любой версии!) Вам никто не запрещает правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е.


Кстати, насколько я помню, возможность правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е появилась всего лишь 8 лет назад )
"Правильная" обработка ошибок не означает "кошерная" (c обязательным использованием конструкции TRY...CATCH).
Нужно просто правильно реагировать в коде на ошибочные ситуации (ну, хотя бы просто проверять @@ERROR после выполнения команд). И такая возможность (обрабатывать ошибки внутри процедур и триггеров) была со времен царя гороха.
22 окт 13, 12:54    [15013901]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
sphinx_mv
"Правильная" обработка ошибок не означает "кошерная" (c обязательным использованием конструкции TRY...CATCH).


+1. И 99% случае будет достаточно:

SET XACT_ABORT ON
BEGIN TRAN
...
COMMIT
22 окт 13, 12:55    [15013931]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
FreemanZAV
sphinx_mv
пропущено...
Сложно воспроизводимая ошибка еще и усугубленная "тяжелыми последствиями" - повод плотно задуматься над дизайном системы.
пропущено...
Ну, так и в MSSQL (любой версии!) Вам никто не запрещает правильно обрабатывать ошибки в процедурах и тригерах - прямо на T/SQL-е.

Это всё верно, но стек всё равно не получить
Ой, да, сколько того стека?! :)
Ограничение уровня вложенности до 32 может местами напрягать, но в реальности это не критично.
С тригерами, допустим, сложнее, но процедура имеет одну "полезную особенность" - всегда можно проверить ее входные параметры и выполнить независимо без "вызывающих". В какой процедуре происходит ошибка - известно (вплоть до номера строки). К тому же, редко стек вызова процедур сильно отличается от списка зависимостей объектов.
22 окт 13, 13:05    [15014017]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Капитан очевидность на проводе
Guest
Infernal V. Raven
Капитан очевидность на проводе
О боже, какой сказочный дол наивный парень! А раскинуть мозгОм самому невдосуг? Ну ок, поясним на пальцах.
У тебя приложение, вставляет по 500-1000 фактов в секунду.

Если так - то согласен. А если 1 факт в минуту? От задачи же ж. Это к слову о том кто "сказочный дол наивный парень!"


То что работает хорошо для 1000 фактов в секунду - будет хорошо работать и для 1 факта.
А вот обратное в общем случае неверно.

Это так, пояснение для сказочных, которым сразу это не очевидно.
22 окт 13, 13:08    [15014049]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

sphinx_mv
редко стек вызова процедур сильно отличается от списка зависимостей
объектов.

Кому нужна процедура, которая вызывается только из одного места?..

Posted via ActualForum NNTP Server 1.5

22 окт 13, 13:08    [15014052]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Капитан очевидность на проводе
Guest
Sergey Orlov
Капитан очевидность на проводе
О боже, какой сказочный дол наивный парень! А раскинуть мозгОм самому невдосуг? Ну ок, поясним на пальцах.
У тебя приложение, вставляет по 500-1000 фактов в секунду. Для окончательного понимания - счетчик показов рекламы, к примеру.
Рассматриваем время реакции на вставку факта и временные затраты серверов (приложения и базы данных).
Вариант первый - приложение само ведет у себя счОтчик и просто сразу прописывает ID в нужном INSERT и в связанных дочерних записях. Одно обращение к серверу - тупо приказать записать все данные в одном PL/SQL блоке.
Вариант второй - приложение сначала делает вставку в сервер, чисто чтоб получить значение ID, потом еще раз должно сходить, уже дочерние записи вставить - итого имеем минимум два обращения на сервер, в режиме "ну ты там БД сервер думай, я пока покурю, от нефиг делать, у меня времени навалом"
Дети, вы такие смешные, право. Неужто самим не очевидно прописное?
.

А чего вызвать функцию или процедуру на сервере с параметрами, которая сразу вставит данные и возвратит id религия не позволяет... Действительно детский сад, в приложении изобретать свой уникальный id...


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


Sergey Orlov
Действительно детский сад, в приложении изобретать свой уникальный id...

Мал ты еще, для high load/high performance, потому действительно - топай в свой уютненький детский садик, с функциями.
22 окт 13, 13:12    [15014077]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
[quot pkarklin]
sphinx_mv
"Правильная" обработка ошибок не означает "кошерная" (c обязательным использованием конструкции TRY...CATCH).


+1. И 99% случае будет достаточно:

[src]
SET XACT_ABORT ON
BEGIN TRAN
...
COMMIT

Все это можно высказать и покороче - "если чего-то нет в mssql, значит это в 99% случаев никому не нужно "
22 окт 13, 13:13    [15014088]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Капитан очевидность на проводе
Guest
Dimitry Sibiryakov
Sergey Orlov
Действительно детский сад, в приложении изобретать свой уникальный
id...

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


Пупсики не увидели слово "сервер приложений" который априори имеет один экземпляр для сотен нефти пользователей, а в случае кластера серверов приложений достаточно работать заранее зарезервированными диапазонами или просто по принципу чет-нечет (один экземпляр вставляет четные, другой нечетные ID, и т.д.) ?

Как мило. Конфетки скушали? Сходите у воспитательницы еще возьмите.

Дима, не всё в этом мире упирается в твою любимую двузвенку на Delphi+Firebird со смешными EhLibами, вылезай уже из погреба-то.
22 окт 13, 13:15    [15014112]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Dimitry Sibiryakov
sphinx_mv
редко стек вызова процедур сильно отличается от списка зависимостей
объектов.

Кому нужна процедура, которая вызывается только из одного места?..
Если Вы умудряетесь вставить вызов неотлаженной процедуры в 100500 мест и не можете найти в каком из них она все-таки падает - ну, и кто Вам после этого персональный доктор?!
22 окт 13, 13:23    [15014205]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 31 32 33 34 35 [36] 37 38 39 40 .. 54   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить