Mysql Создать если не существует иначе обновить

[Юрий Вакуленко]

@antson, подождите.. а как вы предлагаете делать проверку на существование той или иной записи в БД? я что-то не то написал?

если нужно проверить существует та или иная запись - нужно вначале выбрать строки SELECT задав нужные условия выборки через WHERE
и в зависимости от результата - отправлять уже или INSERT или UPDATE ..

Я не прав?
С достаточно мощным процессором и норм. объемом памяти выборка 170 тыс записей через консольную утил. mysql займет не более 600 милисек. конечно на шаред хостинге - это будет значительно дольше! но для серъезных проектов с большой БД не используют шаред хостинги..

 

[Юрий Вакуленко]

@antson, ну 3й вариант решения - мне больше всего нравится. спасибо что пояснили! а как его огранизовать?

второй вариант вы имели ввиду такой вид синтаксиса INSERT ... ON DUPLICATE KEY UPDATE верно? https://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate.html
Страшная фигня еще заключается в том, что в русских мануалах по sql об этом синтаксисе не слова! вот блин переводчики шифраторы..

вот еще также нашел такую зним. статью.. https://habrahabr.ru/post/156489/

 

[AnrDaemon]

ну так а у меня товары постоянно обновляются, как и цены они парсятся, неизменными остаются страны

Как именно у вас обновляются товары? Меняется объём тазиков или машины из переднеприводных становятся полноприводными?

 

[Юрий Вакуленко]

@AnrDaemon, та не издевайтесь вы над человеком)))
может у него тазики каким-то магическим образом превращаются в летающие такизи с посл. трансформацией в лет. тарелку.. нам то откуда знать.. магия то существует и за пределами Хогвардса!

 

[Юрий Вакуленко]

у меня к вам встречный вопрос по теме.. в какой форме в БД лучше хранить историю цен для товара.. ? К примеру, цена может менятся в среднем 1 раз в день.. я думаю лучше хранить цену в формате json строки {"дата" : "цена"} в ячейке с типом LONG TEXT.. но не в виде отдельной таблице из 3х колонок.. (product_id, price_date_changed,price) а как вы думаете? какой оптимальный вариант хранения истории цен применить в БД? А товаров то дофига и трошки будет..

 

[AnrDaemon]

Оптимальный именно последний.
Иначе ты не сможешь получать актуальную цену товара (и, нет, id вовсе не обязательно строго инкрементальный, он только уникальный).

 

[grigori]

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

 

[SnowWind]

Всем спасибо, разобрался, очень помогли

 

[Юрий Вакуленко]

хранить цену в формате json строки {"дата" : "цена"} в ячейке с типом LONG TEXT

здесь я имел ввиду, что эта ячейка будет в таблице product_details (product_id, product_title, product_descr, vendor_id, actual_price, history_price) и в ячейке "history_price" таблицы product_details и будет храниться json строка {"дата" : "цена"} или это отнюдь не хороший вариант?

3й вариант.
использовать отд. таблицу history_price (product_id, vendor_id, history_price) где product_id и vendor_id не автоинкремент и уникальны.. в табл. history_price вообще ячейки с автоинкрем. не будет! а ячейка history_price будет содержать json строку {"дата" : "цена"} и иметь тип LONG TEXT

как лучше организовать?

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

помогите пожалуйста

 

[AnrDaemon]

actual_price, history_price

чо

Поясню - цена это не аттрибут товара. Это настройка магазина.

 

[Юрий Вакуленко]

цена это не аттрибут товара. Это настройка магазина

мне нужно в карточке товара одновременно выводить его актупльную цену .. и ссылку - ИСТОРИЯ ЦЕН.. и при клике на эту ссылку будет яваскрипт библиотекой строится график историч. цен. во всплыв. окне
Поэтому нужно эти исторические цены хранить в БД, чтобы потом на сайт вывести.. вот в каком виде их лучше в БД хранить? какой оптимальный вариант?

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

Опции магазина, чтобы показывал или актуальную цену или историч. цены или и то и другое мне не нужны.. там история цен доступна будет всегда.. тоже самое будет и с историей скидок..
но начать нужно с истории цен.

 

[AnrDaemon]

Нужно - выводи. Не вижу проблемы.

 

[Юрий Вакуленко]

так я и выведу.. но спрашиваю в каком лучше виде эти данные в БД хранить..? в каком из предложенных мной вариантов? или не один из предложенных мной вариантов не является оптимальным?

Нужно - выводи. Не вижу проблемы.

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

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

Возможно, вы уже на темную сторону перешли? Владыка Ситх поработил вашу душу?

 

[SnowWind]

Так, всё же опять запарился, теперь с запросом

Ошибка:
Subquery returns more than 1 row

Запрос:
$sql = "SELECT EXISTS (SELECT * FROM `good`, `country`, `price` WHERE `price`.`goodid` = (SELECT `good`.`goodid` FROM `good` WHERE `good`.`name` = '" . $good. "' )
AND `price`.`countryid` = (SELECT `country`.`countryid` FROM `country` WHERE `country`.`name` = '" . $country. "' ))";

Проблема возникает когда в таблице попадаются дубли, но собственно запрос составляю, для того что бы он их нашёл и не добавлял в таблицу

 

[AnrDaemon]

спрашиваю в каком лучше виде эти данные в БД хранить

Я уже раньше на этот вопрос ответил.

зачем так вредничать

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

Проблема возникает когда в таблице попадаются дубли, но собственно запрос составляю, для того что бы он их нашёл и не добавлял в таблицу

Переведите ваш запрос на русский язык. Я вот так с ходу не могу ответить, что должно быть результатом вашего запроса.

 

[SnowWind]

Переведите ваш запрос на русский язык. Я вот так с ходу не могу ответить, что должно быть результатом вашего запроса.

Есть 3 таблицы

Перед вставкой, проверяю наличие в good сковородки, а в country россия, для чего ищу их id в price следующим запросом

$good = 'сковородка'; $country = 'россия';
$sql = "SELECT EXISTS (SELECT * FROM `good`, `country`, `price` WHERE `price`.`goodid` = (SELECT `good`.`goodid` FROM `good` WHERE `good`.`name` = '" . $good. "' )
AND `price`.`countryid` = (SELECT `country`.`countryid` FROM `country` WHERE `country`.`name` = '" . $country. "' ))";

Первый раз запрос прошёл, когда в good не было сковородки, повторное выполнение приводит к ошибке
Subquery returns more than 1 row

 

[grigori]

Возможно, вы уже на темную сторону перешли? Владыка Ситх поработил вашу душу?

а чувак, вообще, не в курсе куда попал

 

[Юрий Вакуленко]

а чувак, вообще, не в курсе куда попал

это типа я не в курсе куда попал? по тому сленгу, что в статье.. типа я быдлокодер.. ничего не писавший сложнее if..else.. правильно вас понял? .. подвид быдла, в силу ряда субъективных причин не считающий себя таковым. Отличается уверенностью в своей явной богоизбранности и в определенном превосходстве над остальными (хотя 99% небыдла в лучшем случае превосходит только своего соседа алкаша, и то — далеко не факт что).

 

[Фанат]

а чувак, вообще, не в курсе куда попал

Ну и чем здесь гордиться?

 

[Фанат]

зачем так вредничать и умничать?

Ну, строго говоря, он тебе уже ответил, на предыдущей странице:

Оптимальный именно последний.

соответственно, речь о твоем варианте

в виде отдельной таблице из 3х колонок.. (product_id, price_date_changed,price)

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

Любые отступления от этого правила должны иметь ОЧЕНЬ веские основания, причем не из богатого воображения а исключительно из реальных проблем.