Нормализация базы данных SQL с аналогичными данными, управляемыми различными инструментами

Question

Я разрабатываю базу данных для хранения совокупности данных о продуктах, которые вытягиваются через API и очищаются от сети. Этот скребок вытащит некоторые данные, которые являются статическими, и некоторые данные, которые меняются со временем. Поэтому для каждого типа данных (статическая/переменная) будет отображаться одна таблица. Я пытаюсь решить, должна ли быть отдельная таблица для переменных данных, которая очищается по сравнению с переменными данными, которые вытягиваются через API.

Сначала я думал, что они должны храниться в отдельных таблицах, потому что они управляются отдельными инструментами. Однако данные будут извлекаться через API и очищаться по одному и тому же расписанию (ежедневно), и поэтому оба они будут сопоставлены с тем же идентификатором продукта и датой. Таким образом, кажется, что я мог бы просто объединить схему обеих таблиц, чтобы сохранить время соединения во время запросов для обработки данных позже. Очевидным недостатком этого является управление тем, нужно ли создавать или обновлять строки всякий раз, когда выполняется один из процессов (какой из инструментов scraper vs API создает или обновляет строки).

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

Вот пример, если в этом примере все немного облачно. Для этого есть несколько отраслей, но я просто использую недвижимость:
Скребковые статические данные: ProductID, адрес, город, штат, почтовый индекс, квадрат и т. Д.
Скремблированные данные переменной: ProductID, Price, PricePerSqFt и т. Д.
Данные переменных API: ProductID, PageHits, UniqueVisitors и т. Д.

Главным образом здесь важны данные переменной. Итак, просто подведите итоги, разделите таблицы ради общих принципов проектирования или одну таблицу ради скорости на соединениях?

Заранее спасибо за вход

Answer 1

На примере вы даете указывает на то, что, помимо наличия 2 или 3 таблицы, вы должны также рассмотреть вопрос только один стол для статических и переменных данных. Пока ключ всего лишь идентификатор продукта, вы можете хранить всю информацию, описывающую конкретное значение id в одной записи. Или вы намереваетесь иметь отметку времени как часть ключа ваших переменных данных?

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

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

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

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