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

Question

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

Для уточнения:

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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