Я бы использовал хеш, чтобы заполнить первичный ключ и упростить начальный импорт, но при использовании его в дБ всегда рассматривайте его как случайное число. Таким образом, первичный ключ потеряет свое значение (и будет иметь все преимущества автоинкрементного ключа), обеспечивая гибкость в будущем.
ти, мне нужно будет объединить данные о продуктах от нескольких поставщиков в одну базу данных (она, конечно, более сложна), в которой есть несколько таблиц, которые необходимо будет объединить для большинства операций OLTP.
Я собирался придерживаться значения по умолчанию и использовать автоинкрементное целое число в качестве первичного ключа, но в то время как один поставщик предоставляет свое собственное поле «ProductiD», остальные нет, и мне пришлось бы делать много ручного сопоставления с другим затем таблицы для загрузки данных (так как мне нужно было бы сначала загрузить их в таблицу Products, затем вытащить идентификатор и добавить его вместе с другой информацией, которая мне нужна, к другим таблицам).
В качестве альтернативы, я мог бы использовать SKU продукта в качестве его первичного ключа, поскольку SKU уникален для отдельного продукта, и все поставщики предоставляют SKU в своих каналах данных. Если я использую SKU в качестве PK, то я могу легко загрузить потоки данных, поскольку все основано на SKU, как это работает в реальном мире. Однако SKU является буквенно-цифровым и, вероятно, будет несколько менее эффективным, чем целочисленный ключ.
Любые идеи, на которые я должен смотреть?