Valery_BMS SQL + Delphi

Работало хорошо. На 300к+ проводок в день. Но это уже был предел для сервера с 512гб памяти.
Таблицы с > 80млн записей
Сейчас доработали, по нашим оценкам кол-во проводок до 500-700к/деньто ли сиквел такой слабенький то ли сам сервак (хотя памяти-то немеряно) то ли еще где в консерватории
для примера вот оракл на кривом раке о трех нодах (каждый по 64 гб рамы) и 12 самых жирных таблиц (из 1000+ в одной лишь схеме) весят от 1.3 до 14+ ярдов записей. в самую жирную сейчас условно говоря по 35 лямов записей в сутки вставляется
Valery_Bвсё крутиться на MS SQL - и это не правильно и практически вся логика в пакаджах
Valery_BДелая новую СЭДхотя правда это не сэд а биллинг и около него
Valery_Bоднозначно через сервера приложенийгде апсервера по сути лишь прослойки для вызова логики в pl/sql
Valery_BТолько в таком случае получается максимальная производительность и стабильностьи это даже все еще не экзадата. так что подходы разные имеют право на жизнь
хотя конечно в сиквеле возможно все иначе?

Valery_BКоличество записей - не играет особой ролипросто оно зачем-то было конкретно названо и я подумал что причина м.б. в частности именно в кол-ве
Valery_BНичто не помешает сделать 1 проводку, которая будет обрабатываться 1 день на самом крутом серверену так-то да, глотнув фанты можно и не такое затормозить
Valery_BКогда аналитики будут повторно запрашивать данные, для получения которых придётся обработать n-терабайт данных, ты задумаешься о этой прослойкеу нас в системе отчетов кэширование применяется в полный рост, но это ж еще не повод ВСЮ бизнес-логику вытаскивать из базы в апсервера
Alibek B.В СЭД логика может быть сложнойона много где может быть такой
Alibek B.И ее проще делать/поддерживать на сервере приложений, чем в СУБДи зачастую кому-то некоторые задачи проще/удобнее решать именно в базе
Valery_Bдоказывать необходимость апп-серверов я тут не хочуи не надо т.к. при том что я их и сам повсеместно использую вполне отдаю себе отчет что они лишь один из возможных вариантов решения

Valery_BБД должна заниматься таблицами, и больше ничемну если она ничего больше толком не умеет то конечно не стоит и мучить

Alibek B.Реализовать сложную логику может быть проще/дешевле на сервере приложений, чем в СУБДконечно может быть и так но может и ровно наоборот. серебряной пули нет. у меня например часть логики в клиенте, часть в апсервере а часть в базе
Alibek B.лишний слой абстракции обычно добавляет удобстввсяко бывает и порой лучше сделать попроще

во всяком случае существующие условно говоря полмиллиона строк логики на pl/sql в здравом уме переводить в "лишний слой абстракции" пожалуй себе дороже