Являются ли промежуточные таблицы / промежуточные базы данных антишаблоном?

Question

Являются ли промежуточные таблицы антишаблоном, который используется, когда rpc (например, Java RMI или какой-либо вызов веб-службы) или очередь сообщений (например, JMS) были бы лучшим решением, или есть проблемы, лучше обслуживаемые промежуточным размещением таблицы?

Чтобы уточнить:

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

Потенциальные причины этого анти-паттерна:

1) Подразделение Business Unit между владельцами двух процессов предотвращает изменение процесса, выполняющего запись или чтение.

2) Низкая достоверность процесса, который пишет или читает из промежуточного этапа, приводит к тому, что разработчики используют таблицу для предотвращения потери данных "в случае сбоя чего-либо"

3) Недостаток знаний или DGAS (не задавайте ^% $ @) отношение

Answer 1

Промежуточные таблицы, как вы описываете, являются неотъемлемой частью большинства сред хранилищ данных или BI. Можно утверждать, что надежный / отказоустойчивый RPC будет выполнять ту же работу, но я думаю, что вы ошиблись.

Перетаскивая данные в промежуточную таблицу, вы перемещаете их из производственной среды, потенциально для дальнейшего расчета, суммирования, переиндексации, повторного ввода ключей и т. д., большинство из них находятся в базе данных ». Заменив это на RPC, вы перемещаете код и циклы ЦП из БД в сервер приложений без особой выгоды. Например, сервер приложений имеет гораздо большую вероятность сбоя - вы не можете (легко) откатить RPC.

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

Answer 2

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

Answer 3

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

Answer 4

Мой первый ответ - да, но в основном только из-за моей ситуации - ваш может отличаться. У нас есть система, в которой некоторая относительно чувствительная ко времени информация должна переходить от командного компонента к компоненту получателя. Информация о команде помещается в таблицу базы данных, а затем получатель опрашивает таблицу на предмет обновлений. Это ужасно Они сделали это для того, чтобы в базе данных была запись команд, но в итоге это просто заставляет фактическое командование работать вечно, а разъединение иногда приводит к тому, что приемник не синхронизируется с базой данных.

Я бы предпочел, чтобы EMS (например, JMS) транслировал сообщение в тему, которую прослушивают и получатель, и средство вставки базы данных, или в очередь от командира к получателю, а затем получатель уведомляет прослушивателя статуса о том, что его статус в базе данных.

Я не могу дождаться, чтобы исправить этот код.