Объединение хранилища базы данных

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

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

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

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

Answer 2

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

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

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

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

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

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