Унификация хранилища баз данных

Question

Прежде всего, извините за вопрос - я не мог думать о чем-то лучше.

У меня есть интересная проблема.

Есть три веб-приложения:

1. ApplicationA => example.com -> hosted in Germany 
2. ApplicationB => example2.net -> hosted in Australia 
3. ApplicationC => anotherexample.com -> hosted in United States 

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

Теперь, если владелец хочет реализовать любые платные варианты, ему необходимо создать единую систему выставления счетов (в качестве ордеров нумерации счетов должно быть правильно).

Итак, мы имеем ситуацию:

1. user buys a premium option on example.com 
2. another user buys a premium option on example2.net 
3. third and fourth users buy extra options on anotherexample.com 

Таким образом, мы имеем 4 счета-фактуры, поэтому они нумерации должны быть следующие: 2011/01, 2011/02, 2011/03, 2001/04.

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

Теоретически у нас есть только одна проблема: счета-фактуры. Очевидно, нам необходимо создать единую систему хранения счетов-фактур.

Там может быть несколько возможными проблемами:

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

Мне действительно интересно узнать ваши подходы и предложения. Любая деятельность в этом случае высоко ценится.

Answer 1

Во-первых, у меня бы были независимые системы выставления счетов в example.com, example2.net и anotherexample.com, у всех есть свои внутренние первичные ключи для счетов-фактур, генерируемых из каждой из этих систем. Каждая система должна иметь свою собственную независимую копию логики выставления счетов, потому что вы не хотите, чтобы отключение на одном сервере выбивало выставление счетов на каждом сервере.

Всякий раз, когда у вас есть распределенная система, в которой локальные копии создают записи для чего-то, что будет объединено позже, рекомендуется использовать GUID в качестве локального первичного ключа или если у вас есть философское возражение против GUID как ПК, создать идентификатор GUID как кандидат ключ. Таким образом, вы можете объединить счета-фактуры со всех своих систем (и любых будущих), не беспокоясь о ключевых столкновениях, и вы сможете отслеживать объединенные записи обратно в исходные записи, если вам когда-либо понадобится это делать.

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

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

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

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

Answer 2

На мой взгляд, было бы лучше использовать номер закодированного счета. Таким образом, вам не нужно беспокоиться о том, что порядок номеров будет запутан.

Например, для счетов-фактур из Германии для счетов-фактур может быть указан префикс домена, например, de297, de298 и т. Д.

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