[Архит-ра] Стоит ли хранить в БД данные, которые можно получить SQL-ем
на самом деле надо как раз начинать с вопроса производительности. при большом кол-ве товародвижений нормализованнный подход очень тормозит. мы пробовали индексированные вьюхи но с ними еще больший геморой. в итоге остановились аля-регистрах типа 1С
при большом кол-ве товародвижений нормализованнный подход очень тормозиттормозит именно из-за нормолизации?
в приведенном примере, вьюха будет выглядеть следующим образом ... INNER JOIN ... UNION ALL ... INNER JOIN
Тормозит именно INNER JOIN?
да. потом появляется детализация по складам, контрагентам, ед. измерения и.т.д. и все падает. намного быстрее получается залить все проводки в одну-две таблицы и сдалать простейший SUM
потом появляется детализация по складам, контрагентам, ед. измерения и.т.д.для подсчета остатков на складах join-ить со складами не надо, точнее join-ить надо уже результат суммирования, а не всю таблицу с накладными
Оставить комментарий
6yrop
Например, в том же в 1С8.0 при регистрации накладной в системе накладная сама записывается в базу, а так же происходит запись в так называемый регистр накопления, который представляет таблицу с полями (Товар, Склад, Количество). Но если отвлечься от 1С, и смотреть на это просто как на SQL-базу, то этот регистр накопления можно сделать просто вьюшкой над таблицами, в которые записываются первичные документы: приходная, расходная накладные.Какой вариант лучше?
В первую очередь хотелось бы обсудить с точки зрения прозрачности организации кода, гибкости, легкости расширения и сопровождения, устойчивости к ошибкам программирования, легкости тестирования. Мое предположение, что вариант на вьюшках в этом смысле лучше, поскольку первый событийно-ориентирован. С другой стороны, при добавлении (или удалении) нового вида накладной потребуется менять вьюшку, имхо, это не является серьезным недостатком.
Вопросы производительности хотелось бы обсудить позже.