Стратегия хранения дополнительных данных вместе с импортированными данными - PullRequest
Новая
       13

Стратегия хранения дополнительных данных вместе с импортированными данными

0 голосов
/ 21 января 2010

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

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

Много раз мне придется хранить еще какие-то данные, которые относятся к импортированным записям, но не из исходного источника импорта. Обычно эти «дополнительные данные» поступают от пользователя. Итак, я создам другую таблицу с первичным ключом, совпадающим с ключом таблицы, который получает импортированные данные, и сохраню эти дополнительные данные в новой таблице. Если это не имеет смысла, вот пример:

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

Но в моей новой системе сотрудники могут сохранять биографию. Поэтому в другой таблице я храню это и их идентификатор.

Было бы проще иметь только одну таблицу, но я не могу этого сделать, потому что при импорте я бы отбросил данные, которых нет в другом месте.

Еще одна плохая вещь заключается в том, что, поскольку я удаляю все эти записи для импорта, я не могу определить ограничения внешнего ключа для связанных данных.

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

Я использую Sql server 2008, но мне интересно услышать о стратегиях, которые могут работать с любой СУБД.

Ответы [ 2 ]

2 голосов
/ 21 января 2010

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

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

0 голосов
/ 22 января 2010

Вот оператор слияния SQL Server 2008, с которым я пришел, чтобы помочь мне в моей текущей ситуации: 

MERGE INTO dbo.Sections as S        -- Target
USING dbo.SectionsStaging as SS     -- Source
ON S.Id = SS.Id                     -- Join
WHEN MATCHED THEN                   -- Record exists in both tables
    UPDATE SET
        TermCode = SS.TermCode,
        CourseTitle = SS.CourseTitle,
        CoursePrefix = SS.CoursePrefix,
        CourseNumber = SS.CourseNumber,
        SectionNumber = SS.SectionNumber,
        Capacity = SS.Capacity,
        Campus = SS.Campus,
        FacultyFirstName = SS.FacultyFirstName,
        FacultyLastName = SS.FacultyLastName,
        [Status] = SS.[Status],
        Enrollment = SS.Enrollment
WHEN NOT MATCHED THEN               -- Record exists only in source table
    INSERT ([Id],[TermCode],[CourseTitle],[CoursePrefix],[CourseNumber],[SectionNumber],[Capacity],[Campus],[FacultyFirstName],[FacultyLastName],[Status],[Enrollment])
    VALUES (SS.[Id],SS.[TermCode],SS.[CourseTitle],SS.[CoursePrefix],SS.[CourseNumber],SS.[SectionNumber],SS.[Capacity],SS.[Campus],SS.[FacultyFirstName],SS.[FacultyLastName],SS.[Status],SS.[Enrollment])
WHEN NOT MATCHED BY SOURCE THEN     -- Record exists only in target table
    DELETE;

Хорошие вещи!

...