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

Question

Я разрабатываю программу, которая будет создавать и поддерживать базу данных, и выступать в роли центрального сервера. Это «первая стадия» грандиозного плана. Позднее будет 3-5 удаленных программ, построенных на основе информации, помещенной в эту базу данных.

Требования:

1. Удаленные программы должны иметь доступ к информации в базе данных.
2. Удаленные программы должны иметь возможность устанавливать оповещения при изменении информации в базе данных.
3. Удаленные программы должны иметь возможность запрашивать, чтобы центральный сервер вышел и получил новые / другие данные.

Итак, вопрос в следующем: как мне представить эти данные и события внешнему миру? Мои два выбора:

1. Пусть они общаются напрямую с моим «серверным» приложением. Это кажется проще:
   • делать уведомления о событиях (хотя я полагаю, что, возможно, что-то отсутствует в SQL).
   • Также кажется, что это более «обновляемый» вариант - мне не нужно беспокоиться об обновлении базы данных и сбое всех моих удаленных программ, потому что что-то изменилось. Я могу объяснить это и преобразовать данные в версию, понятную для дочерней программы.
2. Просто позвольте им подключиться непосредственно к базе данных.
   • Это хорошо, что решено . Я могу использовать LINQ для SQL. Единственное, что нужно сделать главному серверному приложению, - сообщить удаленным программам, где находится база данных.
   • Я не уверен, как запускать / передавать «события» для изменений полей в базе данных по различным программам, которые могут или не могут быть на одном компьютере.

Прости мое невежество по этому вопросу. Я чувствую себя совершенно не готовым спросить об этом, но мне трудно понять, с чего начать. Это мой первый настоящий проект БД: - /

Спасибо!

Answer 1

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

Answer 2

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

Answer 3

Центральная база данных - это самый простой и дешевый вариант для сборки и обслуживания.

Однако есть несколько сценариев, когда центральная база данных может вызвать проблемы:

• Высокая нагрузкав одной из систем: высокая нагрузка на одну из систем может снизить производительность других систем.Например, кто-то, работающий с внутренним отчетом, лишает вас возможности принимать заказы на вашем сайте электронной коммерции.
• Если несколько систем записывают данные в одну и ту же базу данных, существует большая вероятность блокировки.
• Для нескольких системзависит от той же схемы базы данных, как вы обновляете?Все системы одновременно?
• Если вам нужно снять базу данных, все системы остановятся.

Answer 4

Я рекомендую вам сначала изучить SQL Server и / или базы данных.Похоже, вы не понимаете, что большая часть того, что вы хотите от своего «центрального сервера», может быть выполнена самим SQL Server.

Answer 5

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