SQL Server Альтернатива повторному копированию столбца идентификации

В настоящее время я работаю над приложением телефонной книги. Для этого приложения я получаю плоский файл (csv) из корпоративного SAP, который обновляется ежедневно, что я использую для обновления базы данных sql два раза в день с помощью службы Windows. Кроме того, пользователи могут добавлять себя в базу данных, если они не существуют (т.е.: не включены в файл SAP). Таким образом, контакт может быть двух разных типов: «SAP» или «ECOM».SQL Server Альтернатива повторному копированию столбца идентификации

Таким образом, служба Windows загружает файл с ftp-сервера SAP, удаляет все существующие контакты в базе данных типа «SAP», а затем добавляет все контакты в файл в базу данных. Чтобы вставить контакты в базу данных (около 30 тыс.), Я загружаю их в DataTable, а затем использую SqlBulkCopy. Это работает, в частности, работает всего несколько секунд.

Единственная проблема заключается в том, что первичный ключ для этой таблицы является автоматически увеличивающимся идентификатором. Это означает, что мой идентификатор контакта растет со скоростью 60 тыс. В день. Я все еще в разработке, и мои идентификаторы в области 20mil:

http://localhost/CityPhone/Contact/Details/21026374

Я начал смотреть в пересеве столбца ID, но если бы я переустановка личности к текущему наибольшему количеству в базе данных, следующий сценарий будет представлять проблемы:

службы Windows загружает 30 000 контактов
Пользователь создает запись для себя (ID = 30 001)
службы Windows удаляет все контакты SAP, переустанавливает столбец после текущего наивысшего ID: 30 002

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

источник

2014-11-17 Carel

Нужно ли удалять и вставлять? не можете ли вы обновить существующие записи и вставить новые? –

@SameerAzazi: Причина, по которой я удаляю, а затем вставлять контакты, заключается в том, что каталог всегда должен синхронизироваться с SAP. Это означает, что если у них больше нет контакта в файле, он/она больше не должны находиться в базе данных. Это самый простой способ добиться этого. – Carel

Да. Как бы мы ни обсуждали здесь идентичность, основной проблемой в этом случае является абсолютно неудачный подход к обработке таблицы. Не нужно удалять, а затем вставлять. – TomTom

Предлагаю следующий рабочий процесс.

импорт в новый стол, например tempSAPImport, с вашим текущим рабочим процессом.

Добавить в Вашу таблицу только в строках.

Insert Into ContactDetails 
    (Select * 
    from tempSAPImport 
    EXCEPT 
    SELECT Detail1, Detail2 
    FROM ContactDetails)

Я думаю, что ваша таблица SAP имеет первичный ключ, вы можете использовать контроль, если строка обновляется только.
```
Update ContactDetails (XXX your update criteria) 
```

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

источник

2014-11-17 08:30:23

Если версия SQL Server> = 2012, то я думаю, что лучшим решением для вышеприведенного сценария будет использование последовательности значений PK. Таким образом, вы контролируете процесс посева (вы можете циклически изменять значения).

Подробнее здесь: http://msdn.microsoft.com/en-us/library/ff878091(v=sql.110).aspx

источник

2014-11-17 09:38:55

SQL Server Альтернатива повторному копированию столбца идентификации

ответ

Смежные вопросы