#sql #database-design
#sql #проектирование базы данных
Вопрос:
Я отвечаю за создание базы данных для записи производственных данных.(У меня нет официального опыта работы с базами данных или SQL) с использованием Microsoft SQL
Я могу придумать 2 разных способа структурирования наших данных, которые мы записываем.
1: Я могу записать текущее значение сумматора для каждого материала
2: я могу записать количество, полученное из последней записи.
Некоторая информация, мы будем записывать информацию каждую минуту, чтобы отслеживать производство и количество каждого материала, используемого в миксе.
У нас есть распечатанные отчеты, показывающие, сколько материала и смеси было произведено за определенный день в течение нескольких дней.
Я предполагаю, что мой вопрос сводится к тому, быстрее ли суммировать значения в запросе или искать максимальное значение, связанное с материалом / смесью?
Комментарии:
1. Ваш вопрос мне не очень понятен, не могли бы вы уточнить
2. Такие слова, как «сумматор», «микс» и «материал», ничего не значат, если вы не объясните полный бизнес-контекст данных.
3. Извините, хорошо, давайте предположим, что я делаю лимонад, у меня есть 3 ингредиента: вода, сахар, лимонный сок. моим миксом был бы лимонад. Я хотел бы знать, как лучше всего отслеживать, какие ингредиенты и сколько было использовано. но я должен предположить, что лимонад можно готовить несколько раз в день, и не обязательно спина к спине. и вода может быть в более чем 1 смеси. «сумматор», о котором я говорю, суммирует количество материалов, использованных во время микширования, и сбрасывается при изменении микширования или остановке машины. поэтому я не обязательно могу искать наибольшее количество воды, потому что общее количество будет сбрасываться несколько раз в течение дня
Ответ №1:
Безусловно, будет быстрее найти количество в любой данный момент времени, если запись содержит чистое количество. Затем, когда вы хотите найти количество, вы просто читаете одну запись — последнюю запись или запись на соответствующую дату и время — и выбираете количество. Если вы сохранили дельты, вам придется суммировать их все с нулевого дня.
С другой стороны, если существует несколько независимых источников изменений и / или если изменения могут быть отменены или отменены, то сохранение «текущей суммы» становится проблемой. Что произойдет, если транзакции поступают не по порядку или если старые транзакции изменены или удалены?
Классическим примером этого является баланс банковского счета. Депозиты и снятие средств могут поступать из нескольких источников в непредсказуемое время. Мы часто хотим опубликовать транзакцию не по порядку. Более старая транзакция может быть отменена.
Так, например:
1 января: открыт счет на 1000 долларов. Баланс = 1000 долларов.
2 января: депозит в размере 300 долларов. Баланс = 1300 долларов.
3 января: вывод 200 долларов. Баланс = 1100 долларов.
4 января: проверка, используемая для возврата депозита 2 января. Обратный ввод. Таким образом, баланс на 2 января изменяется на 1000 долларов. Но как насчет баланса на 3 января? Мы должны обновить его до 800 долларов.
В реальной жизни после повторной проверки могла произойти длинная серия транзакций. Если бы мы сохраняли итоговый баланс в каждой записи, каждую из этих записей пришлось бы обновлять.
Дата вступления в силу транзакций часто отличается от даты их ввода в систему. Таким образом, мы обычно обнаруживаем, что транзакции должны быть вставлены в последовательность перед существующими транзакциями, а затем все последующие транзакции должны быть обновлены.
Теперь, возможно, ваш стенд с лимонадом — это другой процесс. Если мы добавляем воду в чашу, мы вполне можем сказать: «добавьте достаточно воды, чтобы довести ее до отметки «полный»», а не «добавьте 4 литра». Если это так — если в большинстве случаев пользователь знает и вводит в компьютер новое общее количество, а не дельту — тогда имеет смысл, что вы вводите общее количество, и если вам важна дельта, вы ее вычисляете. Но если пользователь знает, что это дельта, то он должен ввести дельту, а вы должны перенести дельту и вычислить количество.
Да, проблема в том, что если все, что вы храните, — это дельты, то для вычисления чистого количества требуется суммирование всех записей с нулевого дня. Если количество записей невелико, это может быть вполне приемлемо. Если нет, то, что я иногда делаю, это сохраняю «общие записи» с текущим итогом на некоторую дату. Затем, чтобы получить текущее количество, я нахожу последнюю итоговую запись, а затем добавляю суммы транзакций с этой даты. Это дополнительная нагрузка на код, но значительно повышает производительность.