Мы делаем либо в зависимости от ситуации.
Если сторонние данные должны быть видны обычным пользователям и обычным приложениям, мы помещаем данные туда, где они будут им доступны. В нашем случае эти данные часто представляют собой данные, которые хранятся в настраиваемых таблицах в базе данных, которые можно выбирать, а не редактировать, чтобы пользователи не могли изменять сторонние данные. Если вы используете свои обычные таблицы, вам может понадобиться триггер для предотвращения случайного изменения этих данных. Кроме того, он часто приходит в форме, которая может не соответствовать вашей структуре данных, и если им нужно только проверить это для целей отчета, вы можете не тратить время на его очистку, чтобы ваше обычное приложение могло это принять. ТАК, в этом случае могут потребоваться настраиваемые таблицы.
Например, у третьей стороны может быть поле больше вашего для того же самого. Вы можете избавиться от смысла, усекая их данные, чтобы они соответствовали вашей структуре. Кроме того, ваша структура может иметь набор ограничений, которых не было у сторонних данных. Хотите ли вы рискнуть собственной целостностью данных, удалив эти ограничения? Возможно нет. Если мое приложение считает, что поле должно быть обязательным или иметь действительную дату, я не хочу вносить изменения, чтобы обеспечить хранение данных отчетов сторонних производителей. Если данные могут и должны быть доступны пользователям для изменения (мы делаем это во многих случаях), тогда очистите их до стандартов вашей базы данных и вставьте.
Часто сторонние данные необязательно должны быть видны пользователям, выполняющим регулярный ввод данных, а только в управленческих отчетах, извлеченных из хранилища данных. В этом случае я бы не стал пытаться размещать данные где-либо, кроме хранилища данных. Зачем усложнять жизнь, делая доступными случайные изменения?
person
HLGEM
schedule
09.04.2010
