Меню
Что нового?

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/
 
Последнее редактирование:
SnowWind написал(а):
ну так а у меня товары постоянно обновляются, как и цены они парсятся, неизменными остаются страны
Нажмите для раскрытия...
Как именно у вас обновляются товары? Меняется объём тазиков или машины из переднеприводных становятся полноприводными?
 
@AnrDaemon, та не издевайтесь вы над человеком)))
может у него тазики каким-то магическим образом превращаются в летающие такизи с посл. трансформацией в лет. тарелку.. нам то откуда знать.. магия то существует и за пределами Хогвардса!
 
Последнее редактирование:
у меня к вам встречный вопрос по теме.. в какой форме в БД лучше хранить историю цен для товара.. ? К примеру, цена может менятся в среднем 1 раз в день.. я думаю лучше хранить цену в формате json строки {"дата" : "цена"} в ячейке с типом LONG TEXT.. но не в виде отдельной таблице из 3х колонок.. (product_id, price_date_changed,price) а как вы думаете? какой оптимальный вариант хранения истории цен применить в БД? А товаров то дофига и трошки будет..
 
Оптимальный именно последний.
Иначе ты не сможешь получать актуальную цену товара (и, нет, id вовсе не обязательно строго инкрементальный, он только уникальный).
 
да ладно, в жизни все иначе
сможет он получить актуальную цену - просто добавит поле с 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

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

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

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

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

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

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

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

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

Ошибка:
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. "' ))";

Проблема возникает когда в таблице попадаются дубли, но собственно запрос составляю, для того что бы он их нашёл и не добавлял в таблицу
 
Юрий Вакуленко написал(а):
спрашиваю в каком лучше виде эти данные в БД хранить
Нажмите для раскрытия...
Я уже раньше на этот вопрос ответил.
Юрий Вакуленко написал(а):
зачем так вредничать
Нажмите для раскрытия...
Затем, что решение, найденное самостоятельно, запоминается лучше, чем кем-то подсказанное.
Ну и вообще не имею дурацкой привычки давать очевидные ответы на глупые вопросы.

SnowWind написал(а):
Проблема возникает когда в таблице попадаются дубли, но собственно запрос составляю, для того что бы он их нашёл и не добавлял в таблицу
Нажмите для раскрытия...
Переведите ваш запрос на русский язык. Я вот так с ходу не могу ответить, что должно быть результатом вашего запроса.
 
AnrDaemon написал(а):
Переведите ваш запрос на русский язык. Я вот так с ходу не могу ответить, что должно быть результатом вашего запроса.
Нажмите для раскрытия...

Есть 3 таблицы
table.jpg


Перед вставкой, проверяю наличие в 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% небыдла в лучшем случае превосходит только своего соседа алкаша, и то — далеко не факт что).
 
Юрий Вакуленко написал(а):
зачем так вредничать и умничать?
Нажмите для раскрытия...
Ну, строго говоря, он тебе уже ответил, на предыдущей странице:
AnrDaemon написал(а):
Оптимальный именно последний.
Нажмите для раскрытия...
соответственно, речь о твоем варианте
Юрий Вакуленко написал(а):
в виде отдельной таблице из 3х колонок.. (product_id, price_date_changed,price)
Нажмите для раскрытия...
собственно, тут опять все сводится к вопросу о нормализации БД.
Вариант с нормализованной структуорй БД длжен всегда использоваться по умолчанию, без размышлений - так, как ты ходишь или дышишь. Ты же не думаешь при каждом шаге, какую ногу куда поставить? Ну вот и нормализованная БД всегда должна идти так же.

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