Разделение демонстрационных данных в системе Live - PullRequest
1 голос
/ 03 октября 2008

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

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

Как я упоминал выше, я знаю, что это, вероятно, не лучшая практика. : -)

Ответы [ 4 ]

3 голосов
/ 03 октября 2008

Можете ли вы вместо этого выделить данные в новую базу данных и просто перенаправить строки подключения (они не жестко запрограммированы, верно? Верно?), Чтобы указать на демонстрационную базу данных. Таким образом, живые данные не портятся, и ваш код выглядит идентично. На самом деле мы делаем трехуровневую систему развертывания таким образом, где мы выполняем локальную разработку, развертываем в средах контроля качества, которые каждые несколько месяцев получают моментальные снимки оперативных данных, а затем развертываем в оперативном режиме после завершения тестирования.

1 голос
/ 03 октября 2008

FWIW, мы рассматриваем использование функции безопасности Oracle / виртуальной частной базы данных на уровне строк для отделения демонстрационных данных от остальных.

0 голосов
/ 14 ноября 2008

Совершенно не согласен с Джо. У Oracle есть инструмент для этого независимо от реализации. Прежде чем я прочитал ваш ответ, я собирался сказать VPD ... Но это может оказать влияние на производство.

Помните, что каждая таблица в запросе изменяется с

SELECT * FROM tableA 

до

SELECT * FROM (SELECT * FROM tableA WHERE Data_quality = 'PROD' <or however you do it>

Каждая таблица с политикой, которая ...

Таким образом, если предположить, что ваши тестовые данные должны охватывать КАЖДУЮ таблицу, каждая таблица должна иметь политику, и каждая таблица будет отфильтрована до того, как SQL начнет работать.

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

0 голосов
/ 03 октября 2008

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

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

Вы действительно должны тщательно определить сферу охвата сценариев тестирования / обучения. Например, вы не хотите, чтобы транзакции обучения / тестирования появлялись в производственных отчетах (но вы можете захотеть создавать отчеты с этими данными для обучения / тестирования).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...