Здравствуйте, Gattaka, Вы писали:
G>Можно правами и ролями пользователей базы разрулить если очень хочется...
Не получится. Потому что между пользователем и базой стоит код. И сколько в этом коде багов — никто не знает. Если отобрать у пользователя права, то он не сможет работать.

Здравствуйте, Sinclair, Вы писали:

S>Никакому удалённому клиенту доверять нельзя. Доверенным для RDBMS может быть AppServer, потому что разрабатываем и развёртываем его мы, вместе с базой.
S>Все остальные клиенты — неизвестное зло.

S>Если такое случилось в апп-сервере — мы его чиним. Он под нашим контролем.

Мы выше начали с того, что у нас большая база и несколько приложений, с ней живущих. В общем случае каждое со своим аппсервером и своими клиентами. Все они наши, только возможно поддерживаются разными командами. Зоопарк, в общем. В такой ситуации дублирование логики неизбежно, и, как следствие, рассинхронизация и нестыковки. Тут хранимки ИМХО полезны. Всю логику в них запихивать глупо, но часть можно. Хотя бы базовую валидацию данных, идущих в базу, чтобы ловить эти нестыковки.

W>>Если явный коммит не подтвержден, значит не сработала. Есть другие варианты?
S>Конечно есть. Во-первых, мы вызвали процедуру с автокоммитом.
А не надо с автокоммитом. Хотя если это единственный вызов в транзакции, почему нет.

S>Во-вторых, как вы отличите ситуацию "сервер не подтвердил транзакцию" от "клиент не получил отправленное подтверждение"?
Если это аппсервер, то отличать их нужды нет, так как ситуация "connection reset" нештатная и реакция будет одинаковой: отмена выполняемой задачи (и выкидывание всех промежуточных резульатов), отправка "упс" клиенту и сигнал тревоги админам для ручного разбирательства.

А с удаленным клиентом да, это проблема. Но я сейчас удаленных клиентов не рассматриваю.

W>>И опять же, в чем разница между хранимкой, батчем и серией простых SQL операторов?
S>Речь про разницу между SQL и HTTP как протоколами взаимодействия клиент-сервер.
Понятно, мы немного каждый о своем

Здравствуйте, Sinclair, Вы писали:

S>ХП исполняется настолько же быстро, сколько и эквивалентный ей SQL батч.

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

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Sinclair, Вы писали:

S>>ХП исполняется настолько же быстро, сколько и эквивалентный ей SQL батч.

W>Вот это немного странно для меня. В других СУБД разница бывает хорошо заметной. Ведь затраты на парсинг и семантический контроль никуда не деваются. Особенно если это "горячее" место.

Во всех взрослых базах работает одинаково. Запрос, как и ХП парсится один раз и сохраняется её план. При повторном запросе парсинга не происходит, по хэшу строки запроса\имени процедуры достается из кеша нужный план.
Актуальна разница ХП и adhoc запроса была 20 лет назад.

Здравствуйте, wildwind, Вы писали:


W>Мы выше начали с того, что у нас большая база и несколько приложений, с ней живущих. В общем случае каждое со своим аппсервером и своими клиентами. Все они наши, только возможно поддерживаются разными командами. Зоопарк, в общем. В такой ситуации дублирование логики неизбежно, и, как следствие, рассинхронизация и нестыковки.
В такой ситуации команда, отвечающая за базу, не может доверять командам приложений. Поэтому их надо от базы изолировать путём внедрения своего аппсервера.
Простой пример: bing maps. Команда bing никому не даст прямого доступа к своей геобазе. Все остальные команды MS ходят к bing maps через апп.сервер с хорошо определённым API.
Это позволяет команде перетряхивать внутреннее хранение как им угодно — синхронизовываться надо только со своим же апп.сервером.

W>А с удаленным клиентом да, это проблема. Но я сейчас удаленных клиентов не рассматриваю.
А я как раз рассматриваю. Речь же о нескольких приложениях, которые пишутся разными командами и на разных языках. Если у нас два апп.сервера над базой, и каждый на своём языке, то это ошибка природы.

Здравствуйте, wildwind, Вы писали:
W>Вот это немного странно для меня. В других СУБД разница бывает хорошо заметной. Ведь затраты на парсинг и семантический контроль никуда не деваются. Особенно если это "горячее" место.
Типичная хранимка размером в полсотни килобайт исполняется десятки секунд. Микросекунды парсинга тут незаметны даже в микроскоп. Даже затраты на интерпретацию и те виднее.

Здравствуйте, Sinclair, Вы писали:

S>Это не вопросы привычки. Это вопросы эффективности работы. Зачем заставлять себя писать полсотни килобайт там, где можно написать пять килобайт?
S>Я когда начинал осваивать SQL, то думал как вы. А после нескольких лет работы фактически SQL программистом начал видеть его недостатки.
Почему вы говорите, что на SQL кода получается больше? Хотя на самом деле с точность до наоброт кода колучается меньше причем сильно меньше. Я вам привел в одной из веток пример со списком. Вам чтобы аналог двух строчек на SQL написать нужно написать колосальное количество кода, либо смирится с худшей реализацией.

Здравствуйте, Gattaka, Вы писали:
G>Почему вы говорите, что на SQL кода получается больше? Хотя на самом деле с точность до наоброт кода колучается меньше причем сильно меньше.
Это какое-то недопонимание.
G>Я вам привел в одной из веток пример со списком. Вам чтобы аналог двух строчек на SQL написать нужно написать колосальное количество кода, либо смирится с худшей реализацией.
Можно ещё раз этот пример? Я не вижу кода, о котором вы говорите.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gattaka, Вы писали:

G>>Итак у вас уже словарик rw-локов нужно написать, не много пока. Ну а как вы будете делать блокировки диапозонов? Это еще придумать надо и написать...
G>>А будут ли у вас блокировки о намереньях? А эскалации блокировок у вас будут или все будет по простому и как следствие неэффективно? А средства диагностики у вас какие на коллекции какие будут? Дедлоки как ловить? А что если ваша коллекция не влазит в оперативную память целиком, но вы активно работаете с некоторой частью, то есть имеется активная и пасивная части. Пасивная спокойно никому не мешая может лежать на диске. SQL Server это предоставляет. А фрагментация памяти? Если у вас в середине удаляются записи, сколько коллекция памяти будет занимать? Одним словом, написать что-то похожее на SQL Server сложно и в итоге вы получите SQL Server, только на C# и с багами...

S>Вы это к чему? Я не предлагаю заиенить SQL Server, вы спорите о чём-то не том. Для того, что делает SQL Server, альтернативы, в общем-то нет. Только другие RDBMS того же класса.
S>А вот для того, чему хватит коллекции в памяти, SQL Server будет оверкиллом. С этим лучше заранее смириться, иначе вся жизнь уйдёт на борьбу с ветряными мельницами.

Это я все к тому, что SQL высокоуровневый язык. Если в C# из чего-то подобного есть только garbage collector, в SQL посмотрите сколько всего и эскалации блокировок и т.д. и т.п. Поэтому код на SQL получается компактным и аналогичный код на C# был бы очень сильно больше.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, Gattaka, Вы писали:

G>>>Подозрительная у вас rich model... В частности вызов метод Db.FindContractByEmployee(employee)
G>>>

G>>>foreach(var employee in Db.GetAllEmployees())
G>>>{
G>>>  if (employee.CurrentPosition = position)
G>>>  {
G>>>    var c = employee.Contracts.FirstOrDefault();// Либо Where... все обеспечивается ORM. С linq2db такой код не получится писать я так понимаю. Есть там LazyLoad?
G>>>    c.AdjustSalary(c.CurrentSalary + c.CurrentSalary * 0.10, effectiveDate);
G>>>  }
G>>>}
G>>>

S>>Спасибо за исправление. Lazy Load в linq2db нет, и слава богу. Вы понимаете, чем ужасен этот код?
S>>Если посмотреть на его исполнение под SQL Profiler, то волосы зашевелятся даже там, где их нет.
G>Ну да... у меня может и шевелятся Но есть сторонники, которые начнут доказывать, что это база данных виновата... Давайте на MongoDB переходить, там тормозов нет.
Ну так правильный ответ-то не в монге, и не в хп.
А в

  var employees = from e in db.Employee where e.CurrentPosition = position select e;
  var contracts = db.GetActiveContracts(employees); // from c in db.EmployeeContracts where c.EmployeeId in (from e in employees select id) and c.Status = ContractStatus.Active select c;
  contracts.Insert(db.ContractChange,
     c => new ContractChange {
        ContractID = c.Id,
        EffectiveDate = effectiveDate,
        SalaryAmount = c.CurrentSalary * 1.1
     });

Здравствуйте, Gattaka, Вы писали:
S>>Вы это к чему? Я не предлагаю заиенить SQL Server, вы спорите о чём-то не том. Для того, что делает SQL Server, альтернативы, в общем-то нет. Только другие RDBMS того же класса.
S>>А вот для того, чему хватит коллекции в памяти, SQL Server будет оверкиллом. С этим лучше заранее смириться, иначе вся жизнь уйдёт на борьбу с ветряными мельницами.

G>Это я все к тому, что SQL высокоуровневый язык. Если в C# из чего-то подобного есть только garbage collector, в SQL посмотрите сколько всего и эскалации блокировок и т.д. и т.п. Поэтому код на SQL получается компактным и аналогичный код на C# был бы очень сильно больше.
В C# из "чего-то подобного" есть Linq. Он рвёт T-SQL на тряпки по возможностям декомпозиции. В T-SQL из чего-то подобного linq есть только склейка строк и EXECUTE, которые адски тяжело отлаживать и поддерживать.
Получается, что каждому — своё. На С# мы пишем тяжёлую логику, которую трудно вручную выписывать на SQL. А блокировки и оптимизация планов остаётся в SQL Server.

Здравствуйте, Gattaka, Вы писали:
G> S>В таком сценарии использование ХП — это попытка превратить RDBMS в тот самый апп-сервер. Т.е. клиентам закрывают доступ к таблицам; в лучшем случае даём read-only, хотя даже это адски опасно (потому что всегда есть риск, что мы добавили колоночку типа IsDeleted, а где-то в углу завалялся клиент на дельфи, который ничего про неё не знает, и продолжает хреначить репорты с неуловимо отличающимися от официальных цифр данными).
G> S>Пусть фигачат хранимки.

G> DML — нужно запрещать... У вас ведь с App сервером тоже никто контракт внезапно поменять не может. Добавить поле в DTO IsDeleted?
Не DML, а DDL. DTO к схеме имеет отношение близкое к никакому. Как-то с владением терминологией не очень Вера в то что ХП безусловно быстрее кода. Не способность описать *значущую* бизнес задачу(а не реализацию) для своего примера. Все это очень затрудняет предметный спор.

и ОРМ в чистом виде и DAL на хранимках — оба эти подхода в чистом виде дают одинаково отвратный результат
Не позволяй фанбоям какой-то конкретной технологии запудрить тебе мозг, делай то что выгодно в каждом конкретном случае.
Гибкость в выборе подхода даст куда лучший результат

G>Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы?
Не мода, экономика.
Большинство все равно нихрена в БД не понимает и сделает хуже чем ОРМ

Здравствуйте, gandjustas, Вы писали:

G>И даже банальные расчеты это показывают. Предположим что цена железа растет линейно мощности.
Это верно в весьма небольшом диапазоне.

G> если мы возьмем масштабы гугла или ФБ, то там вертикальное масштаирование или физически невозможно или стоит сильно больше горизонтального.
И ты сам это понимаешь.

G>Но это гугл и ФБ, таких масштабов в жизни мало кто сможет увидеть. А для обычных приложений вертикальное масштабирование выгоднее.
На самом деле упомянутый порог достаточно низок и достигается на раз-2 на сколько нибудь нагруженом ресурсе. А если и статистику считать самостоятельно, и контекстные хинты показывать — то все становистя еще веселей.

G>Почитай про stackoverflow, при их нагрузках они масштабируются вертикально в основном.
А почитай про стоимость и время разработки stackoverflow. В обычном же девелопменте квалификация девелоперов сильно ниже отобранных лично джоелом боевых пидарасов на зп сильно выше средней в нуерке, и тайм прессинг сильнее.

А бывают еще требования по high-availability, которые в принципе невозможно выполнить на одной железяке. Например 99.95% аптайма, которые хотят наверное с половину серьезных заказчиков, прямиком ведет к zero-downtime update. Как ты это заимплементишь на одной железяке?

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>И даже банальные расчеты это показывают. Предположим что цена железа растет линейно мощности.
I>Это верно в весьма небольшом диапазоне.
Это смотря что считать "небольшим". Например на проектах, на которых работают 99% пишущих в этой теме, это верно.

G>>Но это гугл и ФБ, таких масштабов в жизни мало кто сможет увидеть. А для обычных приложений вертикальное масштабирование выгоднее.
I>На самом деле упомянутый порог достаточно низок и достигается на раз-2 на сколько нибудь нагруженом ресурсе. А если и статистику считать самостоятельно, и контекстные хинты показывать — то все становистя еще веселей.
На SO они достигали несколько лет, и по факту пока еще не достигли. В блоге написано, что один веб-сервер может выдержать весь SO. Проектов масшаба SO нет ни у кого из присутствующих, в том числе у тебя.

G>>Почитай про stackoverflow, при их нагрузках они масштабируются вертикально в основном.
I>А почитай про стоимость и время разработки stackoverflow. В обычном же девелопменте квалификация девелоперов сильно ниже отобранных лично джоелом боевых пидарасов на зп сильно выше средней в нуерке, и тайм прессинг сильнее.
И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?

I>А бывают еще требования по high-availability, которые в принципе невозможно выполнить на одной железяке. Например 99.95% аптайма, которые хотят наверное с половину серьезных заказчиков, прямиком ведет к zero-downtime update. Как ты это заимплементишь на одной железяке?
А кто говорил про одну железку? Ты думаешь, что вертикальное масштабирование это когда все на одной железке работает?
И в чем проблема с zero-downtime update? На любой взрослой базе даже проблемы такой нет.

Здравствуйте, gandjustas, Вы писали:
Например на проектах, на которых работают 99% пишущих в этой теме, это верно.
имха цифра в 99% необоснованно завышена.

G>На SO они достигали несколько лет, и по факту пока еще не достигли. В блоге написано, что один веб-сервер может выдержать весь SO. Проектов масшаба SO нет ни у кого из присутствующих, в том числе у тебя.
Смотря что считать проектом масштаба ссо
Если по нагрузке — то у меня был проект в пике нагрузки выходящий на десятки лямов конкурентых сессий. Есснаж команды анадогичной стоимости у меня наверное никогда не будет. Но твоя уверенность в собственном опыте как единственно верном улыбает

G>И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?
Именно. Можно взять середнячков и зарядить их педалить бизнес логику по спеке, не особо задумываясь над тем как оно работает изнутри. И ессна ж они налажают, и тупо дешевле поставить еще пару серваков, чем вылизывать код.

G>И в чем проблема с zero-downtime update? На любой взрослой базе даже проблемы такой нет
Ну давай не будем голословными. Вводная: у тебя пару лямов активных сессий, которые упираются в одну бд в десятки терабайт и необходходимо залить новую версию софта, которая интродюсит изменение схемы данных, которая в свою очередь связана с миграцией данных которая выполняется часы.

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:
I> Например на проектах, на которых работают 99% пишущих в этой теме, это верно.
I>имха цифра в 99% необоснованно завышена.
Только почему-то за все время не объявился никто, у кого проект по нагрузке превосходил бы SO.
Есть отдельные личности с data-intensive задачами, но трафика SO даже близко ни у кого нет.

G>>На SO они достигали несколько лет, и по факту пока еще не достигли. В блоге написано, что один веб-сервер может выдержать весь SO. Проектов масшаба SO нет ни у кого из присутствующих, в том числе у тебя.
I>Смотря что считать проектом масштаба ссо
I>Если по нагрузке — то у меня был проект в пике нагрузки выходящий на десятки лямов конкурентых сессий. Есснаж команды анадогичной стоимости у меня наверное никогда не будет. Но твоя уверенность в собственном опыте как единственно верном улыбает
Что такое "конкурентных сессий" ? Сколько запросов приходилось на фронт-енд?

G>>И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?
I>Именно. Можно взять середнячков и зарядить их педалить бизнес логику по спеке, не особо задумываясь над тем как оно работает изнутри. И ессна ж они налажают, и тупо дешевле поставить еще пару серваков, чем вылизывать код.
Это на стоимость scale up vs scale out не влияет.

G>>И в чем проблема с zero-downtime update? На любой взрослой базе даже проблемы такой нет
I>Ну давай не будем голословными. Вводная: у тебя пару лямов активных сессий, которые упираются в одну бд в десятки терабайт и необходходимо залить новую версию софта, которая интродюсит изменение схемы данных, которая в свою очередь связана с миграцией данных которая выполняется часы.
Я уже рассказывал, возможно прямо в этой теме.
Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.

Здравствуйте, gandjustas, Вы писали:

G>Только почему-то за все время не объявился никто, у кого проект по нагрузке превосходил бы SO.
G>Есть отдельные личности с data-intensive задачами, но трафика SO даже близко ни у кого нет.
Ну они канечно же тебе были обязаны отрепортать в личку — и писатели топика, и читатели

G>Что такое "конкурентных сессий" ? Сколько запросов приходилось на фронт-енд?
Количество уникальных юзверей, зашедших на сайт. Которым необходимо права доступа разграничивать и все такое.

G>>>И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?
I>>Именно. Можно взять середнячков и зарядить их педалить бизнес логику по спеке, не особо задумываясь над тем как оно работает изнутри. И ессна ж они налажают, и тупо дешевле поставить еще пару серваков, чем вылизывать код.
G>Это на стоимость scale up vs scale out не влияет.
Влияет прямиком. Потому что для scale up квалификация команды критична, один кривой запрос положит сервак. А в sсale out все закончится масштабированием.

G>>>И в чем проблема с zero-downtime update? На любой взрослой базе даже проблемы такой нет
I>>Ну давай не будем голословными. Вводная: у тебя пару лямов активных сессий, которые упираются в одну бд в десятки терабайт и необходходимо залить новую версию софта, которая интродюсит изменение схемы данных, которая в свою очередь связана с миграцией данных которая выполняется часы.
G>Я уже рассказывал, возможно прямо в этой теме.
G>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
Ну вот, на время апдейта схемы и кода система лежит. Какой же это 0-downtime?

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Только почему-то за все время не объявился никто, у кого проект по нагрузке превосходил бы SO.
G>>Есть отдельные личности с data-intensive задачами, но трафика SO даже близко ни у кого нет.
I>Ну они канечно же тебе были обязаны отрепортать в личку — и писатели топика, и читатели
Ну конечно же я обязан считать что у всех пипец какие масштабные проекты и все знают о чем пишут

G>>Что такое "конкурентных сессий" ? Сколько запросов приходилось на фронт-енд?
I>Количество уникальных юзверей, зашедших на сайт. Которым необходимо права доступа разграничивать и все такое.
Это за какой период времени? Что за сайт? Сколько запросов на фронтэнд сервер приходится в секунду?

G>>>>И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?
I>>>Именно. Можно взять середнячков и зарядить их педалить бизнес логику по спеке, не особо задумываясь над тем как оно работает изнутри. И ессна ж они налажают, и тупо дешевле поставить еще пару серваков, чем вылизывать код.
G>>Это на стоимость scale up vs scale out не влияет.
I>Влияет прямиком. Потому что для scale up квалификация команды критична, один кривой запрос положит сервак. А в sсale out все закончится масштабированием.
Если один кривой запрос положит сервак, то он с таким же успехом положит и два, и три, и десять.
Или ты думаешь что действие говнокода ограничено одним сервером?

G>>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
I>Ну вот, на время апдейта схемы и кода система лежит.
С чего ты взял?

Здравствуйте, wildwind, Вы писали:

IT>>Я бы сказал так. Увидели хранимку — отбейте железной ленейкой руки тому, кто это сделал. Не существует ни одного реального аргумента, почему ХП должны ещё жить. И уж точно масштабируемость тут ни при чём.

W>Странно слышать столь категоричные утверждения от человека с большим опытом.

Вот как раз большой реальный опыт и позволяет делать такие утверждения.
У нас, кстати, linq2db используется на базе размером около терабайта, если что. Полёт — отличный.