Лучший способ рассчитать сумму в зависимости от даты с SQL

Question

Я не знаю хорошего способа вести суммы в зависимости от дат в базе данных SQL.

Взять базу данных с двумя таблицами:

Клиент

• clientID
• имя
• просроченоAmount

Счет

• clientID
• invoiceID
• сумма
• dueDate
• paymentDate

Мне нужно предложить список клиентов и заказать его по просроченной сумме(сумма неоплаченных прошлых счетов клиента).В большой базе данных невозможно рассчитать ее в режиме реального времени.

Проблема заключается в сохранении поля просроченной суммы на клиенте.Сумма этого поля может изменяться в полночь с одного дня на другой, даже если в счетах клиента ничего не изменилось.

Эта сумма изменяется, если счет оплачен, создан новый счет и срок оплатыВ прошлом, срок оплаты уже прошел, а не вчера ...

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

Я думаю, что это общая проблема, и я хотел бы знать, существует ли лучшая практика?

Answer 1

Вы должны прочитать о хранилище данных. Это поможет вам решить эту проблему. Это похоже на то, что вы только что сказали

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

Но в этом есть нечто большее. Когда вы читаете это, попробуйте забыть о нормализации. Его основное предназначение - «показывать» данные, а не «управлять» данными. Так что вначале вы будете чувствовать себя странно, но если вы поймете, «зачем нам нужно хранилище данных», это будет очень и очень интересно.

Это книга, которая может стать хорошим началом http://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimensional/dp/0471200247, классическая.

Answer 2

Во-первых, я хотел бы понять, что вы подразумеваете под «очень большими базами данных» - большинство систем СУБД, работающих на достойном оборудовании, должны иметь возможность рассчитать это в реальном времени для чего-либо менее чем сотен миллионов счетов.Я говорю здесь из опыта.

Во-вторых, «наилучшая практика» - это одно из тех выражений, которые очень мало значат - оно часто используется для представления чьего-либо мнения как более значимого, чем просто мнение.

По моему мнению, безусловно, лучший вариант - рассчитать его на лету.

Если ваша база данных настолько велика, что вы действительно не можете этого сделать, я бы подумал о ночной партии (как вы описываете).Ночные пакетные прогоны - это боль, особенно для систем, которые должны быть доступны 24/7, но они имеют преимущество, сохраняя всю логику в одном месте.

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

Однако триггеры - это неприятные, злые вещи с экзотическими режимами сбоев, которые могут поставить в тупик ничего не подозревающего разработчика, поэтому учитывайте это только при наличии ниндзяРазработчик SQL под рукой.Обязательно убедитесь, что у вас есть SQL-запрос, который проверяет правильность вашей таблицы unpaid_invoices, и в идеале запланируйте его как обычную задачу.