ну не знаю... у меня есть апи к базе электронных компонентов... себе все миллиарды позиций все равно не вытянешь, да еще и наличие с ценой регулярно меняется.
AlikDex: ну, даже в ой статье есть merge join, который вполне может работать для одинаково отсортированных таблиц, соединяя их за один проход, без цикла в цикле (nested loops).
MaxKorz: не совсем так. null не чем не лучше, чем 3.1415926. просто значение примитивного типа. еще раз спрошу про то, зачем замыкание? лучше бы избавится от глобальной переменной вообще. ну, или не на null её проверять, а на state.
myspace: ну, принцип тот же - для именованных плейсхолдеров - заменяем на именованные с суффиксом-номером. для ненумерованных - заменяем на нужное количество знаков вопроса через запятую, но это сложно, если плейсхолдера больше одного.
alexdora: индексы очень хорошо работают при отборе по = по колонке с большим количеством уникальных значений. а вообще нужно почитать даже не про индексы, а про explain у mysql, планы запросов у mssql и подобные вещи у других субд
я так понимаю, есть две таблицы - таблица движений и таблица итогов
три подхода - запретить заднее число (вводить поступления корректировку текущим числом с соответствующим пересчетом итога)
"восстанавливать последовательность", пересчитывая всю "себестоимость" начиная от удаленного документа, возможно неоперативно (не в момент удаления документа, а регламентной операцией)
убрать сумму (или писать некоторую плановую цифру) в итоговой таблице и из списаний вообще и рассчитывать факт её регламентной операцией при закрытии месяца.
ну и правильный вариант вообще отказаться от самописки и взять типовую 1с... потому что потом захочется вешать допзатраты, налоги, незавершенное производство и далее по нарастающей
