Константин, хз. Говорю же, я смутно эту систему понимаю. primary_key по моему разумению ставится на уникальное значение, которое может выступать однозначным указателем. В таблице brands_state может быть два одинаковых значения id_brand, например когда бренд принадлежит двум группам. Или два бренда одной группе. То есть в поле id_brand (id_group) значение неуникально. А foreign_key указывает, (опять же, как я это понимаю), что значение поля id_brand может принимать весь диапазон значений brands.id и в случае удаления/изменения brands.id выполняется какое то действие с таблицей brands_state, обеспечивающее целостность данных.
SELECT id, name FROM tbl
WHERE
name="bla_bla_bla"
AND START_DATE>=200005
AND IF(END_DATE=0, DATE_FORMAT(CURRENT_TIMESTAMP, '%Y%m'), END_DATE)<=200005
Выводит ровным счетом нифига. Думаю тут дело не в приведении дат, а что то с алгоритмом. Читал тут в интернетах что такое безобразие делается через BETWEEN, но что то тоже не соображу как это сделать
Philipp: Говорят, физически что то из бд удалять плохо, фрагментация и все такое. В таблице backet_state у позиции в корзине указывается ее текущий статус. Допустим "В корзине", "Удален", "Нет в наличии" и все такое. Представим что, человек отправляет позицию из корзины в работу. По хорошему надо скопировать всю информацию из корзины (количество, цена и все такое) в отдельную таблицу, где будет хранится содержимое заказа. А это уже избыточность данных. Я вижу выход в том, чтобы просто поставить определенной позиции в корзине статус "В работе", создать новую записать в orders и для этой записи в таблице соотношений проставить id позиций в корзине со статусом "В работе". А чтобы в коде это вот все не писать, я переношу всю эту логику на плечи БД. А как INSERT SELECT работает я не знал, думал что на уровне самой бд это будет работать как цикл, интерпретатор разобьет эту конструкцию на много маленьких инсертов и на каждом следующем инсерте будет возвращать мне last_insert_id предыдущей вставки. Поэтому и спросил у многоуважаемого сообщества, корректно ли все отработает. Но нет, движок базы умный=)
А я почему то думал что будет типа такого что подзапрос SELECT из второго инсерта выберет, допустим, пять записей и этот инсерт начнет их как в цикле вставлять в таблицу order_state, а LAST_INSERT_ID() в лучшем случае не будет возвращать ничего, так как автоинкрементных полей в order_state нет
Philipp: 1. Поменять статусы в корзине. 2. Создать новый заказ. 3. Привязать элементы корзины, у которых поменялись статусы, с свежесозданному заказу. И все это одной процедурой
Николай Конюхов: Ладно, окей. Предположим, с деревом вопрос решили. Теперь надо выбрать все товары, принадлежащие данной ветке. Та же самая байда - на таком объеме селект по tree_id занимает несколько секунд драгоценного времени. Как ускорить селект на 147 миллионах записей?
Это все конечно хорошо, но дело то не в этом. На самой структуре дерева все хорошо. Дело в выборке из 147 миллионов записей.
Можно вообще упростить вопрос до: "Как сделать быструю выборку MySQL на больших объемах данных?".
Максим Федоров: Это не моя структура к сожалению. Это структура одного очень известного софтварного продукта для поиска аналогов автозапчастей и не на Mysql а на Transbace =) Но спасибо за помощь, все заработало =)
Максим Федоров: Между Поставщиками и товарами - нигде. А между товарами и брендами в таблице с товарами. Но если имя поставщика совпадает с именем бренда, то id бренда == id поставщика