- Обновляет все предыдущие значения в таблице для того же продукта, что не соответствует действительности.
Необходимо указать точно , какие записичто вы хотите обновить. База данных не имеет автоматического понятия «предыдущие» значения, даже если у вас есть поле даты или несколько строк с одинаковым Product_Name. Оператор делает именно то, что вы сказали ему сделать ... обновить любую и все строки, которые соответствуют именам в соответствии с WHERE Product_Name = StoringTF.Product_Name. Почему вы ожидаете, что он сделает что-то иначе?
Он вычисляет среднее значение для несуществующих продуктов, что приводит к неправильному значению магазина.
По сути, это та же проблема, что и первая: база данных будет содержать все строки. которые соответствуют вашему состоянию. Вы сказали, что группа только на Product_Name, так что это то, что он сделал. Еще раз не существует автоматического понятия «несуществующий» продукт. Вы должны добавить что-то в свое предложение WHERE и / или обновить предложение GROUP BY, чтобы отличить существующие продукты от несуществующих продуктов. Вы даже не предоставили достаточно информации другому человеку, чтобы определить этот факт, так как бызнаете, что база данных исключает «несуществующие» продукты?
- Я хочу, чтобы она вставлялась только для этой вставляемой строки и не редактировала предыдущие строки
Ваш код выполняет инструкцию UPDATE. Если вы хотите вставить новую строку, то вам нужно сделать именно это ... выполнить инструкцию INSERT. Оператор UPDATE обновляет существующие строки. Инструкция INSERT вставляет новые строки.
Во-вторых, я хочу рассчитать его только для существующих продуктов
Тот же ответ для первых двух пунктов.
Я предлагаю исследовать нормализацию данных. Основная идея нормализации данных состоит в том, чтобы избежать избыточной и дублирующей информации. В реляционной базе данных это делается путем создания нескольких таблиц, которые связаны с первичными и внешними ключами.
Например, в одной таблице вы определяете продукты только с информацией, которая не меняется со временем ... что-то вроде Product_Name или Product_Code, и присваивает уникальные значения ProductID каждой строке. Определите отдельную таблицу для каждого магазина с различными сведениями о магазине и уникальным значением первичного ключа StoreID.
В другой таблице хранятся такие транзакции, как покупка и продажа. Таблица транзакций будет включать столбцы ProductID и StoreID внешнего ключа. Вы на самом деле не храните информацию о товаре или магазине в таблице транзакций, только суммы в долларах и другие детали транзакции. Все детали о продуктах и магазине извлекаются через значения идентификатора внешнего ключа. Еще лучше разделить продажи и покупки на отдельные таблицы, но это еще один сложный шаг.
Дополнительные предложения начинают выходить за рамки этого одного вопроса, но существуют и другие способы нормализации транзакционных данных, чтобыстановится легче получать последние средние значения и выбирать «только текущие продукты» и т. д.
Предлагаемое частичное решение
Несмотря на мои лучшие суждения, я выкладываю более подробную информациючто я надеюсь будет полезным. StackOverflow в целом стал намного более открытым и терпимым в отношении публикации длинных, полных решений.
Следующее не является каким-либо полным решением, но оно содержит образец схемы и запросы, которые можно использовать как частьполное решение. Все необходимые детали не понятны из вопроса, но следующее демонстрирует некоторый уровень нормализации. Я, конечно, не включаю какой-либо запрос на миграцию для существующих данных, так как эти усилия и детали должны обрабатываться OP.
Это все еще не отвечает на вопрос о выборе «только существующих продуктов», потому что это то, что вам нужно определить дальше. Я понятия не имею, что означает «только существующие продукты». Вы имеете в виду только товары на складе? Из вашей табличной схемы неясно, храните ли вы общее количество элементов в каждой строке или является ли каждая строка отдельной транзакцией.
CREATE TABLE Stores (
Store_code INTEGER PRIMARY KEY,
Store TEXT NOT NULL UNIQUE
)
CREATE TABLE Products (
Product_Code INTEGER PRIMARY KEY,
Product_Name TEXT NOT NULL UNIQUE,
Description TEXT,
Product_Date TEXT -- Is this the transaction date?
)
-- Not exactly sure what these columns are for,
-- so I don’t know precisely where they fit in a normalized schema
-- Permission INTEGER, -- Not sure what this is for
-- Incoming INTEGER, -- Same as purchased quantity?
-- Outgoing INTEGER, -- Same as sold quantity?
CREATE TABLE Sales (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
Store_code INTEGER NOT NULL REFERENCES Stores(Store_code),
Product_Code INTEGER NOT NULL REFERENCES Products(Product_Code),
TransactionDate AS DATETIME,
Unit_Sell_Price CURRENCY NOT NULL,
Quantity INTEGER NOT NULL
)
CREATE TABLE Purchases (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
Store_code INTEGER NOT NULL REFERENCES Stores(Store_code),
Product_Code INTEGER NOT NULL REFERENCES Products(Product_Code),
TransactionDate AS DATETIME,
Unit_Buying_Price CURRENCY NOT NULL,
Quantity INTEGER NOT NULL
)
Следующий запрос демонстрирует, как вставить новые приобретенные продукты. Этот оператор INSERT использует синтаксис параметров SQL, чтобы указать, что ему нужны входные значения из языка / среды, внешней по отношению к базе данных SQLite. (Детали того, как правильно выполнить такое утверждение, включая передачу входных значений, здесь не описаны, и их следует исследовать отдельно.)
INSERT INTO Sales (Store_code, Product_Code, TransactionDate, Unit_Sell_Price, Quantity)
VALUES (@storecode, @productcode, @trandate,
(SELECT AVG(Unit_Buying_Price) AS AveragePrice
FROM Purchases
WHERE Store_code= @storecode AND Product_Code = @productcode),
@quantity)
Обратите внимание, что итоговые цены не сохраняются ни в одном из них. Таблицы транзакций Sales или Purchases, скорее итоги рассчитываются динамически с помощью запроса, подобного следующему.
CREATE VIEW PurchaseDetails AS
SELECT *, Unit_Buying_Price * Quantity AS Total_Buying_Price
FROM Purchases