Прежде всего, я прошу прощения за длину. Это довольно сложно (по крайней мере, для меня).
Справочная информация в базе данных:
У меня есть таблица продуктов, переменных и цен. «Продукты» - это основная информация о продукте (описание, название и т. Д.). «Цены» содержат информацию о каждой цене (цена, стоимость, минимальное кол-во, стоимость доставки и т. Д.), Поскольку некоторые продукты могут иметь более одной цены (10-дюймовый виджет отличается от 12-дюймового, например) , «Переменные» - это варианты товара, которые не меняют цену, например цвет, размер и т. Д.
Первоначально (когда я создавал эту базу данных около 7 лет назад) у меня была переменная информация, хранящаяся в первой цене в списке цен на тот же продукт в формате с разделителями по конвейеру (да, я знаю, badbadbad). В целом это работало, но у нас всегда была проблема, хотя иногда переменная не была бы согласованной среди всех цен.
Например, виджет (продукт) может быть 10 "или 12" и продаваться за 10 и 20 долларов (цены) соответственно. Однако, хотя 10-дюймовый виджет может быть доступен в синем и красном цвете (переменные), 12-дюймовый виджет доступен только в красном. Мы исправили эту проблему, добавив небольшое выражение в скобках в неконгруэнтную переменную, такую как «Красный (ТОЛЬКО 10»). Этот вид работает, но клиенты не всегда настолько умны, и много времени уделяется исправлению ошибок, когда клиент выбирает 12-дюймовый виджет красного цвета.
С тех пор мне было поручено модернизировать базу данных, и я решил поместить переменные в их собственную таблицу и сделать их более динамичными и удобными для сопоставления с определенными ценами, а также сохранить более фиктивный инвентарь (вы можете ' не представляю себе кошмаров).
Моим первым шагом было написать хранимую процедуру в моей тестовой базе данных (для того, когда я делаю преобразование), чтобы обработать все существующие переменные в новую таблицу переменных (и таблицу меток, но это не очень важно, я не считать). Я эффективно проанализировал переменные и перечислил их с правильным идентификатором продукта и идентификатором продукта, с которым они были первоначально связаны в таблице переменных. Однако я понял, что это только часть проблемы, поскольку я (по крайней мере, для первоначального преобразования базы данных) хочу, чтобы каждая переменная была указана как связанная с каждой ценой для данного продукта.
Для этого я создал еще одну таблицу, например:
tblvariablesprices
variablepriceid | variableid | priceid | productid
, который является многим ко многим с таблицей переменных.
Проблемы:
Моя проблема в том, что я не знаю, как создавать строки. Я могу создать левое соединение в своих таблицах цен и переменных, чтобы получить (я думаю) все необходимые данные, я просто не знаю, как их пройти. Мой sql (mysql 5.0):
SELECT p.priceid, p.productid, variableid, labelid
FROM tblprices p
LEFT JOIN tblvariables v ON p.priceid = v.priceid
ORDER BY productid, priceid
Это даст мне все priceid и productid, а также любые соответствующие переменные и идентификаторы меток. Это хорошо в некоторых случаях, например, когда у меня есть что-то вроде:
priceid | productid | variableid | labelid
2 | 7 | 10 | 4
2 | 7 | 11 | 4
2 | 7 | 12 | 4
3 | 7 | (null) | (null) --- another price for product
потому что теперь я знаю, что мне нужно создать запись для priceid 2 и variableids 10, 11, 12, а затем также для priceid 3 для этого продукта. Однако я также получаю результаты из этого набора данных для продуктов без переменных, продуктов с одной ценой и несколькими переменными и продуктов с несколькими ценами и без переменных, например:
priceid | productid | variableid | labelid
2 | 7 | 10 | 4
2 | 7 | 11 | 4
2 | 7 | 12 | 4
3 | 7 | (null) | (null)
4 | 8 | (null) | (null) --- 1 price no variables
5 | 9 | 13 | 5 --- mult vars, 1 price
5 | 9 | 14 | 5
5 | 9 | 15 | 6
5 | 9 | 16 | 6
6 | 10 | (null) | (null) --- mult price, no vars
7 | 10 | (null) | (null)
8 | 10 | (null) | (null)
Используя приведенный выше набор данных, я хочу добавить записи в мою таблицу tblpricesvariables следующим образом:
variablepriceid | variableid | priceid | productid
1 | 10 | 2 | 7
2 | 11 | 2 | 7
3 | 12 | 2 | 7
4 | 10 | 3 | 7
5 | 11 | 3 | 7
6 | 12 | 3 | 7
7 | 13 | 5 | 9
8 | 14 | 5 | 9
9 | 15 | 5 | 9
10 | 16 | 5 | 9
У меня есть тысячи записей для обработки, поэтому, очевидно, что делать это вручную - это не ответ. Может ли кто-нибудь хотя бы указать мне правильное направление, если не придумать звездочку, которая могла бы справиться с этим типом операции? Я также приветствовал бы любые комментарии о том, как лучше организовать и / или структурировать эти данные.
Большое спасибо за то, что прочитали все это и помогли мне.