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-сериализованными данными в таблицу товаров :)
а проблемы будет решать другой программист, которого наймут, когда сайт перестанет работать, а этого может даже и не уволят - я таких встречал
 
хранить цену в формате 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

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

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

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

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

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

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

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

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

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

Фанат

oncle terrible
Команда форума
зачем так вредничать и умничать?
Ну, строго говоря, он тебе уже ответил, на предыдущей странице:
Оптимальный именно последний.
соответственно, речь о твоем варианте
в виде отдельной таблице из 3х колонок.. (product_id, price_date_changed,price)
собственно, тут опять все сводится к вопросу о нормализации БД.
Вариант с нормализованной структуорй БД длжен всегда использоваться по умолчанию, без размышлений - так, как ты ходишь или дышишь. Ты же не думаешь при каждом шаге, какую ногу куда поставить? Ну вот и нормализованная БД всегда должна идти так же.

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