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

Откуда: 127.0.0.1
Сообщений: 67383
Блог
SergSuper
я и Вам завидую - у меня их 50000))

Не знаю, о чём идёт речь, но на всякий случай скажу, что к архитектуре той системы я... не имел особого отношения. И многие её решения считаю, мягко говоря, неудачными. Что не отменяет того простого факта, что для реализации тривиальной функциональности "стек вызовов своими руками" пришлось бы взять весь ИТ-отдел и на сколько-то недель засадить переписывать и перетестировать весь хранимый код, и энтузиазм коллеги Сфинкса по этому поводу я как-то не разделяю.
22 окт 13, 20:08    [15017136]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Гость333
SergSuper
пропущено...

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

50000 чего? Пакетов? ХП?
увы, пакетов
часть правда сгенерирована автоматически, но думаю не больше четверти
22 окт 13, 21:43    [15017422]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
SergSuper
50000 чего? Пакетов? ХП?
увы, пакетов
часть правда сгенерирована автоматически, но думаю не больше четверти[/quot]
Честно говоря, не очень представляю, какую одну задачу стоит решать таким количеством осмысленного (?) кода. Даже если кто-то решал вопрос зависимостей методом "каждой хранимке свой пакет".
22 окт 13, 22:48    [15017600]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
softwarer
SergSuper
50000 чего? Пакетов? ХП?
увы, пакетов
часть правда сгенерирована автоматически, но думаю не больше четверти

Честно говоря, не очень представляю, какую одну задачу стоит решать таким количеством осмысленного (?) кода. Даже если кто-то решал вопрос зависимостей методом "каждой хранимке свой пакет".[/quot]Напр., разбор китайских прайс-листов 50000 разных форматов и их продажа посредническим интернет-магазинам. Посмотрел мимоходом, что сооружают для Амазона --- это полный атас.
22 окт 13, 22:52    [15017614]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

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

Как-то приставка "нано-" затерялась в этом уже распиливаемом проекте...

Posted via ActualForum NNTP Server 1.5

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

Откуда: Новосибирск
Сообщений: 20368
Капитан очевидность на проводе
iv_an_ru
Вообще-то есть ещё вариант третий --- приложение дёргает хранимку, которая и ID получит, и дочерние записи вставит, и понаделает при необходимости ещё кучу всякого, и всё это без IPC посреди транзакции. И вариант четвёртый --- веб сервер в самой СУБД, так что хранимка сама делает всю рутину, и только в случае какой-нибудь экзотики дёргает внешнюю логику на hosted language.


Есть еще пятый вариант - когда веб сервер, сервер баз данных и application user land - все крутится в одном физическом процессе
Это как раз и есть четвёртый вариант, и ждать для этого ничего не надо, "это" в продаже с 95-го, прости Господи, года.
22 окт 13, 23:03    [15017667]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
iv_an_ru
softwarer
пропущено...
увы, пакетов
часть правда сгенерирована автоматически, но думаю не больше четверти

Честно говоря, не очень представляю, какую одну задачу стоит решать таким количеством осмысленного (?) кода. Даже если кто-то решал вопрос зависимостей методом "каждой хранимке свой пакет".Напр., разбор китайских прайс-листов 50000 разных форматов и их продажа посредническим интернет-магазинам. Посмотрел мимоходом, что сооружают для Амазона --- это полный атас.
кто говорит что одну задачу? насчет осмысленности тоже иногда сомневаюсь)
и разбор нескольких сотен форматов тоже есть

очень комплексная система с реализацией чего только можно и начатая реализовываться много лет назад

Сообщение было отредактировано: 22 окт 13, 23:50
22 окт 13, 23:49    [15017760]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Капитан очевидность на проводе
Guest
iv_an_ru
Капитан очевидность на проводе
пропущено...


Есть еще пятый вариант - когда веб сервер, сервер баз данных и application user land - все крутится в одном физическом процессе
Это как раз и есть четвёртый вариант, и ждать для этого ничего не надо, "это" в продаже с 95-го, прости Господи, года.


Прикольно. Тут кто-то усиленно трет описание архитектуры. Это ты стучишь в обком, давишь будущих конкурентов?
22 окт 13, 23:57    [15017777]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

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

Глубокомысленная вода там, где, видимо, нечего сказать по делу. Если попытаться соотнести это высказывание с предыдущими, получается, что "работать неправильно" - это такой изысканный "способ исключительной обработки неправильных входных данных". Забавно, забавно.
Не более забавно, чем уровень Ваших претензий на отсутствие "стека" в MSSQL.
softwarer
sphinx_mv
У меня каждый последовательный этап обработки набора данных фиксируется изменением его состояния. Соответственно, в любой момент я могу прервать или восстановить обработку с точки останова в соответствии с текущим состоянием.

Ага, уже показались пять золотых. Если копнуть ещё немного, окажется, что "наборы данных" у Вас в общем не поражают разнообразием и довольно стабильны (потому как зависят от аппаратуры),
И всего-то нужно под каждый тип девайсов иметь профиль управления и сбора данных... И типов девайсов совсем ничего - штук 50... Разного назначения...
И фигня, что после смены фирмвари некотрые девайсы начинают "слегка шалить" - это легко резолвится фиксами во время тестовых прогонов.
softwarer
процедур их обработки, соответственно, тоже сравнительно немного, и именно поэтому путей вызова немного, зависимости легко прослеживаются и стек вызовов, в общем, не нужен. Угадал?
Але! Гараж! Вы в курсе, что максимальная вложенность вызовов хранимых процедур ограничена 32 уровнями (и проектировать систему на MSSQL надо в том числе и с учетом этого ограничения)?
Для того, чтобы заблудиться в этих максимум 32 уровнях вложенности вызовов хранимых процедур надо обладать весьма особым уровнем одаренности.

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

А у меня скромный (объем данных всего гигов на 25 в месяц) такой биллинг телекоммуникационный под интернет (выделенные линии и диалап), фиксированную телефонию, VoIP (карточный и транзит), с авторизацией, с ЛЮБЫМИ извращениями в тарифных планах (препэй, постпэй, бонусы) - и все на хранимых процедурах. И ни у одного "коммерсанта"/"маркетолога" не хватит мозгов, чтобы придумать фишку, которая уже не реализована.
softwarer
sphinx_mv
А давайте Вы не будете мне рассказывать, как автоматически сливать и обрабатывать данные, приходящие из разных источников. Ок? :)

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

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

О, уже появился номер строки. Интересно, откуда :)
Матчасть, однако... Демонстрируется примером наколенного говнокода...
Вот Вам процедура:
CREATE PROCEDURE Test @ch int
AS
BEGIN
    declare @i INT
    if @ch = 1
        set @i = 1 / 0 -- Line 6
    else
        set @i = 1 / 0 -- Line 8
END

А вот Вам сообщения, которые выводятся в процессе ее выполнения с разными параметрами:
EXEC Test 1
---
Msg 8134, Level 16, State 1, Procedure Test, Line 6
Divide by zero error encountered.

EXEC Test 2
---
Msg 8134, Level 16, State 1, Procedure Test, Line 8
Divide by zero error encountered.

Можно было еще пользовательский RAISERROR влепить, но "общего представления" и так для достаточно.
softwarer
sphinx_mv
более чем достаточно для любой диагностики.

Да-да. Примените это к приведённому мной примеру, посмеёмся вместе. Итак, дано: таблица, по ночам в некоторых записях некоторое (имевшее значение) поле сбрасывается в 0, что является непосредственной причиной наблюдаемых проблем. Рассказывайте, как будете диагностировать настоящую причину.
А че тут думать?!
Констрэйнтами пользоваться надо!
Тригерами, хранимыми процедурами для изменения данных, если констрэйнты не нравятся - и диагностировать ничего не придется: сервер САМ все за всех продиагностирует.
softwarer
sphinx_mv
К тому же (если действительно припрет) обеспечить передачу ошибки в вызывающие процедуры, чтобы построить "стек вызовов", проблемы (на самом деле) не представляет.

Не представляет. Если не считать того, что довольно геморройно кодировать. Я понимаю, что Вы ориентируетесь на свои десять ХП, но их бывает и тысяча. В той системе, о которой идёт речь, только пакетов было порядка сотни, как мне помнится.
(Зевая) Тысяча хранимых процедур... сотня пакетов... Этой "линейки" не достаточно, чтобы меня удивить/испугать...
У самого штук 800 одних только таблиц... Тысячи полторы хранимых процедур. На большинстве таблиц тригера. На некоторых из таблиц до десятка триггеров наберется - но таких не много... Это только в как бы "главной" базе данных. Есть еще штук 10 вспомогательных и архивных. Репликация между разными базами работает - включая разнотипные сервера баз данных...
softwarer
И если бы я посоветовал им перекомпилить весь хранимый код, аккуратно при этом вставив в каждую хранимку "вход в хп такую-то", "выход из хп такой-то", "второй-третий-четвёртый return-ы из хп такой-то", "возбуждение исключения в хп такой-то", "необработанное исключение, приводящее к выводу из хп такой-то".... В общем, я весьма благодарен вендору, который избавил меня от такой работы.
Ну, а кто Вам виноват, что Вы изначально криво спроектировали и реализовали систему, а теперь не можете свести в ней концы с концами? К серверу-то тут какие претензии?!
softwarer
sphinx_mv
Это тот самый "неуловимый Джо", котрый никому он не нужен, и которого никто не ловит.

Столь яркая любовь к словам типа "никто" и "никогда" имхо свойственна людям лет в двенадцать.
Лет в 12-ть пора уже знать, что козе баян нафиг не нужен.
22 окт 13, 23:57    [15017778]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
iv_an_ru
Напр., разбор китайских прайс-листов 50000 разных форматов

Я не зря упомянул про "осмысленного" и "стоит". Конечно, можно посадить пятьсот китайских программистов с котлом риса в день, но я надеюсь, это не вариант Сергея.

SergSuper
кто говорит что одну задачу?

Контекст беседы. Они должны быть как-то связаны между собой кроме присутствия на одном сервере.

SergSuper
очень комплексная система с реализацией чего только можно и начатая реализовываться много лет назад

Ну вот всё равно не очень представляю. Мне кажется, в такое количество серверного кода можно впихнуть помимо комплексной задачи ещё и автокад с фотошопом и место всё равно останется :) Видимо, это из серии "надо видеть".
23 окт 13, 00:08    [15017800]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
ОперацияПингвин
Member

Откуда:
Сообщений: 653
Блог
google всех порвет
23 окт 13, 00:22    [15017825]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
sphinx_mv
Але! Гараж! Вы в курсе, что максимальная вложенность вызовов хранимых процедур ограничена 32 уровнями (и проектировать систему на MSSQL надо в том числе и с учетом этого ограничения)?
Для того, чтобы заблудиться в этих максимум 32 уровнях вложенности вызовов хранимых процедур надо обладать весьма особым уровнем одаренности.
32 - достаточно для того, чтобы заблудиться. Не понимаю, зачем отрицать очевидное, что стек процедур ускоряет дебаг.
sphinx_mv
Ну, а то что правильное разделение системы по функционалу не приводит к возникновению кросс-референсов - к бабке не ходить! И нужно-то всего лишь контролировать что, откуда и когда вызывается - и будет счастье во веки веков.
(устало) как правильно-то?
sphinx_mv
А у меня скромный (объем данных всего гигов на 25 в месяц)
Ну хороший объем, но, согласись, не заоблачный. У многих коллег и побольше будет. И это не повод вести себя бескомпромисно в вопросах архитектуры.
sphinx_mv
Слияние данных из разных источников - это, кстати, если Вы еще не в курсе, тоже репликация.

Отнюдь. Это интеграция. На крайний случай импорт.
sphinx_mv
Матчасть, однако... Демонстрируется примером наколенного говнокода...
Вот Вам процедура:
CREATE PROCEDURE Test @ch int
AS
BEGIN
    declare @i INT
    if @ch = 1
        set @i = 1 / 0 -- Line 6
    else
        set @i = 1 / 0 -- Line 8
END

Как бывшему разработчику SQL бросается в глаза отсутсвие SET NOCOUNT ON. Надеюсь это не ты писал?
23 окт 13, 10:35    [15018712]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
sphinx_mv
Матчасть, однако... Демонстрируется примером наколенного говнокода...
Вот Вам процедура:
CREATE PROCEDURE Test @ch int
AS
BEGIN
    declare @i INT
    if @ch = 1
        set @i = 1 / 0 -- Line 6
    else
        set @i = 1 / 0 -- Line 8
END


А вот Вам сообщения, которые выводятся в процессе ее выполнения с разными параметрами:
EXEC Test 1
---
Msg 8134, Level 16, State 1, Procedure Test, Line 6
Divide by zero error encountered.

EXEC Test 2
---
Msg 8134, Level 16, State 1, Procedure Test, Line 8
Divide by zero error encountered.


Можно было еще пользовательский RAISERROR влепить, но "общего представления" и так для достаточно.

ну а теперь вынесите деление в отдельную процедуру ...
23 окт 13, 11:17    [15019088]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
SergSuper
sphinx_mv
Матчасть, однако... Демонстрируется примером наколенного говнокода...
Вот Вам процедура:
CREATE PROCEDURE Test @ch int
AS
BEGIN
    declare @i INT
    if @ch = 1
        set @i = 1 / 0 -- Line 6
    else
        set @i = 1 / 0 -- Line 8
END


А вот Вам сообщения, которые выводятся в процессе ее выполнения с разными параметрами:
EXEC Test 1
---
Msg 8134, Level 16, State 1, Procedure Test, Line 6
Divide by zero error encountered.

EXEC Test 2
---
Msg 8134, Level 16, State 1, Procedure Test, Line 8
Divide by zero error encountered.


Можно было еще пользовательский RAISERROR влепить, но "общего представления" и так для достаточно.

ну а теперь вынесите деление в отдельную процедуру ...
Не в одельную процедуру, а в тяжёлый покупной модуль, где оно гавкнется на пятом уровне вложенности.

У меня был феерический баг: на карте родного Новосибирска зациклилась "городская" транспортная задача, долгая отладка показала, что я напоролся на невероятное сочетане данных: четыре случайные точки, заданные в целых сантиметрах на территории в квадратный километр, абсолютно точно легли на одну прямую. Модельный пешеход, отправляясь из A в D, входил строго в точку B забора BC, подвернувшегося строго по дороге, и зависал, не в силах осознать, с какой же стороны забора он оказался. Вот как такое разобрать без стека?
23 окт 13, 11:29    [15019231]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Infernal V. Raven
sphinx_mv
Але! Гараж! Вы в курсе, что максимальная вложенность вызовов хранимых процедур ограничена 32 уровнями (и проектировать систему на MSSQL надо в том числе и с учетом этого ограничения)?
Для того, чтобы заблудиться в этих максимум 32 уровнях вложенности вызовов хранимых процедур надо обладать весьма особым уровнем одаренности.
32 - достаточно для того, чтобы заблудиться. Не понимаю, зачем отрицать очевидное, что стек процедур ускоряет дебаг.
И что, так и будем использовать все 32 уровня до полного исчерпания?! Чтобы в "очень обозримом" будущем попасть на Msg 217, Level 16, State 1, ака, "maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)"?!
Десять уровней вложенности уже следует рассматривать как "за гранью разумного" (т.к. в системе еще есть тригера, процедуры и представления)

Просто напоминаю: это - не ассемблер! Это даже не дельфи!.. Это - эмэсэскьюэль и транзакт-эскьюэль...
И еще раз напоминаю - на этом "счастье" можно дебажить и разбирать критические ситуации при отсутствии всякого встроенного "стека вызовов" - разбор и обработка ошибок однако... Плюс самое главное - знание своей системы.
Infernal V. Raven
sphinx_mv
Ну, а то что правильное разделение системы по функционалу не приводит к возникновению кросс-референсов - к бабке не ходить! И нужно-то всего лишь контролировать что, откуда и когда вызывается - и будет счастье во веки веков.
(устало) как правильно-то?
Взбодритесь!
Правильно - это когда сопровождение не вызывает непосильных проблем.
Кто-то может поручиться, что после добавления новой "вундервафли" с очень сомнительной полезностью все проблемы разработчиков баз данных на MSSQL рассосутся раз и навсегда? Терзают очень смутные сомнения... И как-то радует, что аналогичные сомнения терзают и разработчиков сервера...
Infernal V. Raven
sphinx_mv
А у меня скромный (объем данных всего гигов на 25 в месяц)
Ну хороший объем, но, согласись, не заоблачный. У многих коллег и побольше будет. И это не повод вести себя бескомпромисно в вопросах архитектуры.
Реакция на архитектуру с "детскими" проблемами не поддерживает фичу "компромисс".
И еще не люблю, когда коллеги достают "несертифицированные линейки"...
Infernal V. Raven
sphinx_mv
Слияние данных из разных источников - это, кстати, если Вы еще не в курсе, тоже репликация.

Отнюдь. Это интеграция. На крайний случай импорт.

Из не самого "надежного" источника, но как вариант:
Репликация — это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот.
Импорт... Копирование(уже было)... Загрузка... Выгрузка... Синхронизация...
Что еще "не попадает" под процитированное определение? :)
Infernal V. Raven
sphinx_mv
Матчасть, однако... Демонстрируется примером наколенного говнокода...
Вот Вам процедура:
CREATE PROCEDURE Test @ch int
...

Как бывшему разработчику SQL бросается в глаза отсутсвие SET NOCOUNT ON. Надеюсь это не ты писал?
Читаем выделенное... Просветляемся...
23 окт 13, 11:32    [15019268]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
sphinx_mv
И что, так и будем использовать все 32 уровня до полного исчерпания?! Чтобы в "очень обозримом" будущем попасть на Msg 217, Level 16, State 1, ака, "maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)"?!
Десять уровней вложенности уже следует рассматривать как "за гранью разумного" (т.к. в системе еще есть тригера, процедуры и представления)

Что-то я не понимаю, это твои слова:
sphinx_mv
Для того, чтобы заблудиться в этих максимум 32 уровнях вложенности вызовов хранимых процедур надо обладать весьма особым уровнем одаренности.

Противоречие однако.
sphinx_mv
Просто напоминаю: это - не ассемблер! Это даже не дельфи!.. Это - эмэсэскьюэль и транзакт-эскьюэль...
И еще раз напоминаю - на этом "счастье" можно дебажить и разбирать критические ситуации при отсутствии всякого встроенного "стека вызовов" - разбор и обработка ошибок однако... Плюс самое главное - знание своей системы.
Это никак не противоречит тому, что со стеком это делать удобнее. Кроме того персонал имеет свойства меняться и чтобы приобрести это "знание" системы в ней надо основательно поковыряться. Чем разнообразнее и качествены средства, тем быстрее это произойдет
sphinx_mv
Правильно - это когда сопровождение не вызывает непосильных проблем.

softwarer привел конкретную проблему и способ решения. Я не увидел описания того как ты бы диагностировал эту ситуацию. Следовательно, есть подозрение, что это стало бы непосильной проблемой.
sphinx_mv
И еще не люблю, когда коллеги достают "несертифицированные линейки"...

Не уловил суть аналогии
sphinx_mv
Из не самого "надежного" источника, но как вариант:
Репликация — это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот.
Импорт... Копирование(уже было)... Загрузка... Выгрузка... Синхронизация...
Что еще "не попадает" под процитированное определение? :)

Целиком:
Репликация (англ. replication) — механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация — это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот.
Т.е. механизм синхронизации, а копирование - средство.
23 окт 13, 13:01    [15020087]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
sphinx_mv
(Зевая) Тысяча хранимых процедур... сотня пакетов... Этой "линейки" не достаточно, чтобы меня удивить/испугать...
У самого штук 800 одних только таблиц... Тысячи полторы хранимых процедур. На большинстве таблиц тригера. На некоторых из таблиц до десятка триггеров наберется - но таких не много... Это только в как бы "главной" базе данных.

Мягко говоря, по-опыту - это не лучшее архитектурное решение.
23 окт 13, 13:20    [15020230]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
Infernal V. Raven
Мягко говоря, по-опыту - это не лучшее архитектурное решение.

странный у вас опыт. По нему должно быть как - вообще без триггеров и процедур? или без процедур? Или триггеров должно быть в N раз больше, чем таблиц?
Прикладные (а не архитектурные) решения бывают разными, есть люди делают все на процедурах, а есть делают сервера приложений с базами не то что без процедур и триггеров, но и без FK. И судить о таком решении можно только если полностью его изучить.
Кстати, архитектурно решения могут быть разными например в MS SQL и Firebird, при этом обе базы могут иметь примерно одинаковое количество таблиц, процедур и триггеров.
23 окт 13, 13:53    [15020502]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2112
Infernal V. Raven
sphinx_mv
(Зевая) Тысяча хранимых процедур... сотня пакетов... Этой "линейки" не достаточно, чтобы меня удивить/испугать...
У самого штук 800 одних только таблиц... Тысячи полторы хранимых процедур. На большинстве таблиц тригера. На некоторых из таблиц до десятка триггеров наберется - но таких не много... Это только в как бы "главной" базе данных.

Мягко говоря, по-опыту - это не лучшее архитектурное решение.


+1 сам работаю сейчас с подобной системой, моё имхо такое, что надо запретить триггеры)
23 окт 13, 13:56    [15020525]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
sphinx_mv
Не более забавно, чем уровень Ваших претензий на отсутствие "стека" в MSSQL

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

sphinx_mv
Вы в курсе, что максимальная вложенность вызовов хранимых процедур ограничена 32 уровнями

Да, я слышал про такую фигню в MSSQL. На взгляд со стороны она не представляется мне сильно сдерживающей, за исключением явной неразумности использования рекурсии. Во всяком случае, я не считаю её заметным недостатком сервера.. скажем, ограничение длины идентификаторов в Oracle представляется мне столь же нелепым и более геморройным фактором.

sphinx_mv
А у меня скромный (объем данных всего гигов на 25 в месяц)

Когда Вас спрашивают про сложность логики, а Вы в ответ про объёмы данных...

sphinx_mv
Ну, и сколько в Вашей базе таблиц, в которых хотя бы пол-сотни полей?

Вы деликатно забыли спросить, сколько в них строк? :) И не приплетайте констрейнты, они тут не в тему.

sphinx_mv
А вот Вам сообщения, которые выводятся в процессе ее выполнения с разными параметрами:
Msg 8134, Level 16, State 1, Procedure Test, Line 6
Divide by zero error encountered.

И именно они идут как основа диагностики?

Хм. Спасибо, я и забыл, как весело было отлаживаться на MSSQL. Правда, тут я сам отчасти виноват - к тому моменту я плотно привык к работе с исключениями и было трудно восстанавливать привычку после каждой строчки кода добавлять if @@error <> 0 или как там...

sphinx_mv
А че тут думать?!

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

sphinx_mv
(Зевая) Тысяча хранимых процедур... сотня пакетов... Этой "линейки" не достаточно, чтобы меня удивить/испугать... У самого штук 800 одних только таблиц... Тысячи полторы хранимых процедур. На большинстве таблиц тригера. На некоторых из таблиц до десятка триггеров наберется

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

sphinx_mv
Ну, а кто Вам виноват, что Вы изначально криво спроектировали и реализовали систему,

Примерно тот же, кто виноват в Вашем беспомощном хамстве.

sphinx_mv
К серверу-то тут какие претензии?!

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

sphinx_mv
Лет в 12-ть пора уже знать, что козе баян нафиг не нужен.

Я не привык ассоциировать собеседников с животными, но раз Вы самоидентифицировались, буду иметь в виду.
23 окт 13, 13:57    [15020534]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Melkomyagkii_newbi
.... моё имхо такое, что надо запретить триггеры)

Ну в Аксцессе их типа нет.

Но если буите выносить на правительство такую инициативу, в Оракле, плиз, оставьте их. Иначе мы напишем в СПОРТЛОТО.
23 окт 13, 14:07    [15020623]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

Melkomyagkii_newbi
надо запретить триггеры)

Ага, и курсоры тоже. Поскольку у MS SQL и то и другое кривое.

Posted via ActualForum NNTP Server 1.5

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

Откуда: из прошлого
Сообщений: 2112
Dimitry Sibiryakov
Melkomyagkii_newbi
надо запретить триггеры)

Ага, и курсоры тоже. Поскольку у MS SQL и то и другое кривое.


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

Откуда: St.Petersburg
Сообщений: 1710
kdv
странный у вас опыт. По нему должно быть как - вообще без триггеров и процедур? или без процедур? Или триггеров должно быть в N раз больше, чем таблиц?
Прикладные (а не архитектурные) решения бывают разными, есть люди делают все на процедурах, а есть делают сервера приложений с базами не то что без процедур и триггеров, но и без FK.
С ХП, но желательно без триггеров. Если и с триггерами, то не в таком диком количестве. Причины отказа в системах от FK, которые встречались были следующие:
1. БЛ целиком находится на апп-сервере, а к БД он обращается только как к хранилищу данных
2. Просадка производительности при их использовании
3. (условно, поскольку, вероятно, проектирование просело) Использование FK достаточно серьезно усложняет БЛ.

kdv
И судить о таком решении можно только если полностью его изучить.
Кстати, архитектурно решения могут быть разными например в MS SQL и Firebird, при этом обе базы могут иметь примерно одинаковое количество таблиц, процедур и триггеров.

Решения и должны быть архитектурно разными, ведь используются разные инструменты.
Уточню - мое мнение, насчет "не самой удачной архитектуры" касалось учетных и биллинговых систем.
23 окт 13, 15:03    [15021102]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
Infernal V. Raven
С ХП, но желательно без триггеров. Если и с триггерами, то не в таком диком количестве.

триггер триггеру рознь. где то их нет, а где то они есть, но такие разные, что одни лучше других. Вы про "без триггеров" в MS SQL?

А насчет "отказа от ФК" - разные причины бывают, но уж никак не пункты 2 и 3. Собственно, "отказ от FK" еще неким образом сигнализирует о том, что либо работа с БД производится монопольно, либо в БД поддерживается duty read. Потому что даже на ReadCommited, не говоря про Snapshot, в двух разных транзакциях без ФК целостность соблюсти не удастся.
Например, иногда люди в Firebird/InterBase пытаются FK на триггерах имитировать, не понимая, что это работать не будет. То есть, будет, но при жестких условиях, не допускающих удалений и определенных модификаций в справочнике, и т.д.
Тем самым, если такие запреты на триггерах не делать, опять же усложняется бизнес-логика сервера приложений.
23 окт 13, 15:26    [15021327]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 33 34 35 36 37 [38] 39 40 41 42 .. 54   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить