Результаты поиска

Задать вопрос
Найдено результатов: 2

Как мне организовать мой мастер ddl скрипт

В настоящее время я создаю master ddl для нашей базы данных. Исторически мы использовали резервное копирование / восстановление для версии нашей базы данных, а не поддерживали какие-либо сценарии ddl. Схема довольно большая.

Мое нынешнее мышление:

  • Разбейте скрипт на части (возможно, в отдельных скриптах):

    1. создание таблиц
    2. добавление индексов
    3. добавить триггеры
    4. добавить ограничения

  • Каждый сценарий вызывается главным сценарием.

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

Еще какие-нибудь советы?

Edit: также, если кто-то знает хорошие инструменты для автоматизации части процесса, мы используем MS SQL 2000 (старый, я знаю).

sql   sql-server   schema   ddl    

533   7   16:03, 1st July, 2020


Сборщик/раздатчик сообщении, он же «message broker»?

Имеется необходимость разработать middleware-модуль: сборщик/раздатчик сообщении, он же «message router», он же «message broker», он же «message orientated middleware». За громкими названиями в текущей реализации — простая суть: клиенты рассылают сообщения (асинхронно), сообщение доходит до broker’а (пока буду называть так требуемый сборщик/раздатчик), он его каким-то образом обрабатывает и придерживает до того момента, как его не запросит получатель сообщения (тот, кому оно предназначалось).

Получатель запрашивает сообщения, сообщения передаются получателю – всё на этом работа broker’а закончена.


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


Вторая – использовать БД для хранения сообщений – при «интенсивном» получателе будет постоянно генерировать запросы к БД.

Финальный (текущий) вариант – использование памяти для очередей ссылок на сообщения, которые хранятся в НЕ-SQL БД (из преимуществ – не требует настройки БД, из недостатков – недостаточно быстрый старт (считываются очереди сохраняемые в момент остановки) и чувствительность к штатной остановке (могут не записаться текущие очереди)).


Интересует вопрос, кто создавал подобные решения?

Требования простые:

  1. малое потребление памяти
  2. быстрый старт
  3. возможность обрабатывать сообщения большого размера, при небольшом кол-ве самих сообщений
  4. желательно отсутствие необходимости создавать БД



Т.к. требования достаточно противоречивы – выставлены в порядке убывания приоритета.


Так же интересует вопрос отдачи сообщений получателю – кто какие шаги использует (уведомления об обработке, периодический опрос, подписка на тип сообщений и пр….)


P.S.: Готовые программные продукты неподходят так как требуют дополнительных ресурсов, настройки и предполагают, что архитектура будет строится вокруг них, а для меня это просто средство создания асинхронного обмена сообщениями — возможно потом это будет объединено в 1 exe-файл.

Middleware    

373   2   17:07, 15th August, 2020