Бредятинаprog123С появлением SSD-дисков, у которых время доступа на чтение в разы стало больше, остатки можно делать чисто вычисляемыми на лету.
Фундаментально))) С опорой на скорость чтения с диска делать приложения, работа которых замедляется с течением времени)))

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

Бредятинаcaballeroпропущено...


суть не в дисках а в том что разработка ПО стоит дороже железа. Вместо диска можно напихать гигабайтов памяти выделить большой кеш для сервера БД и все эти таблицы будут работать еще быстрее чем на SSD.
Предоставьте, пожалуйста расчет, с учетом того, что ПО все равно разрабатывается (не разрабатывается только его небольшая часть, которую предлагается "заменить" железом).
пример выше. выгрести остатки одним простым запросом или городить систему запоминания остатков по периодам с соответствующим гемором при выборке

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

Любая БД со временем будет работать медленнее. Во всяком случае я еще не встречал серверов БД скорость работы которых возрастает при увеличении обьема данных.

Бредятина,

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

Иначе в чем заключается "медленность приложения со временем", Процессор износится от пересчета таблицы?

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

Бредятина,
еще раз для тех кто в танке - ЛЮБОЕ приложение будет работать медленнее по мере накопления данных НЕЗАВИСИМО от того каким образом запрограмировано получение этих данных. Так что вы хотите доказать?

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

Arm79,

свертка не имеет отношения к сути вопроса - если есть возможно оптимизировать Бд ею пользуются.
Сколько бы клиентов и записей ни было - пересчет данных (суммирование оборотов для получения остатка будет идти по строкам выбранных в соответствии с индексом (который как правило кешируется в памяти).
Безусловно по мере разрастания данных выборка для пересчета будет медленнее, но это касается и ЛЮБОЙ другой выборки, например какого нибудь поиска.
Но наличие большого обьема памяти позволит серверу Бд кешировать наиболее часто запрашиваемые данные в памяти. Как правило большинство отчетов делаются за определенный период - текущий месяц, квартал и т.д. Поэтому боьшая вероятность что после первой выборки для пересчета части таблиц с оперативной информацией за этот период окажутся закешированными. Впрочем это тоже касается любой выборки.
С другой стороны - у нас тысячи клиентов и по каждому (точнее по каждому счету если их у клиена больше одного) надо хранить остатки например на начало месяца - тоже нехилый обьем. При выборке нам надо вычислить от каких остатков плясать - обратится к таблице остатков, затем обратится к таблице движений чтоы получить обороты и просуммировать. не уверен что это будет намного быстрее не говоря уже о более сложной выборке (уж точно не простейший select sum() как при пересчете).
ну и плюс еще эти остатки надо высчитывать и запоминать. и хорошо если в системе не надо проводить операции задним числом (лично я в наших реалиях таких не видел) с последующим песчетом остатков как в той же 1С.
С третьей стороны - на примере работы с приват24 я вижу что данные все равно получаются не сразу. я не знаю как там у них написано - но я делаю транзакцию а результат (обновление на странице или СМС на телефон приходит иногда чере несколько минут). а раз добится мгновенного отклика системы все равно нельзя (или просто не имеет смысла) то чего усложнять систему.
А для манаегров которые там просматривают всякие сводные данные как правило строятся всякие олапы с предагрегациями - но это уже совсем другая задача с другими методами.
Как бы там ни было даже если окажется в далеком будущем что есть необходимость хранить промежуточные остатки (ы чем я лично сомневаюсь глядя как растет производительность серверов) это можно будет сделать потом не переделывая всю систему. На данный момент вполне можно руководсвоватся дним из програмистских правил - преждевременная оптимизация - зло.

Впрочем как говорят в Одессе - это "мое ИМХО". Истина только в бенчмарках :)

Dimitry SibiryakovcaballeroЛЮБОЕ приложение будет работать медленнее по мере накопления данных
НЕЗАВИСИМО от того каким образом запрограмировано получение этих данных. Так что вы
хотите доказать?
Он хочет сказать, что если приложение не программировать, то оно и не будет работать
медленнее. Сферические кони в вакууме не замедляются.

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