Что лучше: PHP или SQL?

Афраний писал(а)
хитрые PHP-запросы нагрузят сервер не меньше

что за запросы?

лучше питон и тарантул блеать :) лучше в каждом случае разное. угадать что такое лучше в этом конкретном случае без примера - разговор ни о чем. :)

Допустим, есть жёстко зашитый список товаров (таблица goods). Для каждого товара имеется картинка. Товары имеют определённые категории (таблица categories). А ещё товар с одним и тем же названием может быть в нескольких разных вариантах фасовки. Допустим, пицца разных диаметров. Поэтому есть таблица для описания реальных товаров (goods_real), в которой указан параметр нетто и его единица измерения (вес в граммах, объём в миллилитрах или диаметр пиццы в сантиметрах). Соответственно, торговая точка выбирает товары из списка и хранит свой ассортимент (таблица goods_shop). Там же указана цена товара и его наличие.

А теперь нам надо вывести список всех товаров в магазине...
Я пока не добавил наличие и название категории, но запрос выглядит примерно так:
SELECT _id,rgid,(SELECT goods FROM goods_real WHERE rgid=goods_shop.rgid) as ggid,(SELECT categ FROM goods WHERE goods.goods=ggid) as categ,price,(SELECT netto FROM goods_real WHERE rgid=goods_shop.rgid) as netto,(SELECT measure FROM goods WHERE goods.goods=ggid) as measure,(SELECT gimg FROM goods WHERE goods.goods=ggid) as pic,(SELECT title FROM goods WHERE goods.goods=ggid) as title FROM goods_shop WHERE shop_id=1;

Типа так --->

Вот финальная версия запроса --->

По-моему, достаточно просто реляций (OneToMany и т.п.). Хранимые процедуры тут ни к чему.

Может быть. Спасибо за подсказку, буду иметь в виду.

1. В 9 случаев из 10 хранимые быстрее.
2. Как нравится так и делай, с хранимыми права проще будет разрулить (если надо), как минимум.

От запроса глаза закровоточили, это что? JOIN для кого придуман ?

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

Категорию можно сделать как parent в goods, минус лишняя таблица, на вкус и цвет.

Хранит ассортимент, цену, остатки goods_shop....
Я бы разделил.
Отдельно прайс, отдельно стоки.

И вообще для таких запросов достаточно вьюшку сделать, будет еще проще.

Афраний писал(а)
Aria

Mariadb дремучая больно. Обновляйся и уходи на INNODB.

Спасибо, конечно, я просто SQL ещё не сильно хорошо знаю и не слишком активно работал с JOIN. SKU - это что?

Замысел: продавцы в свой ассортимент берут товары из списка, но при этом могут указывать свою цену и свой комментарий.
По наличию есть два варианта: либо учитывать, либо нет.
То есть если наличие не учитывается, клиент может хоть миллион экземпляров товара заказать. Если учитывается, то клиент закажет не больше, чем есть в наличии - но тогда продавцу нужно будет держать эти цифры актуальными.

Категории товаров имеют древовидную структуру.

1. В смысле "дремучая"?
2. Почему не на XtraDB?

Если как ты писал выше, у тебя есть
Шаверма от Ашота в goods
и есть
50 гр.
100 гр.
150 гр.
Распиханные в goods_real

SKU - это _конкретный_ товар, в нашем случае Шаверма от Ашота + 50 гр.
Это реализуется через Foreign Key, но ARIA в него не умеет, лучше документацию глянуть.
Можно обойтись костылем, и хранить id goods_real в goods и каждый раз это кодом обрабатывать.

Дерево можно строить и по одной таблице


А можно завести в goods
id name
1 Шаверма от Ашота 50 гр.
2 Шаверма от Ашота 100 гр.
3 Шаверма от Ашота 150 гр.
Ключ таблицы goods уникален будет в данном случае.

Афраний писал(а)
SELECT _id,rgid,(SELECT goods FROM goods_real WHERE rgid=goods_shop.rgid) as ggid,(SELECT categ FROM goods WHERE goods.goods=ggid) as categ,price,(SELECT netto FROM goods_real WHERE rgid=goods_shop.rgid) as netto,(SELECT measure FROM goods WHERE goods.goods=ggid) as measure,(SELECT gimg FROM goods WHERE goods.goods=ggid) as pic,(SELECT title FROM goods WHERE goods.goods=ggid) as title FROM goods_shop WHERE shop_id=1;

запрос ужасен, имхо. просто почитайте про sql ansi 92, архитектуру данных, констрайнты и индексы и т.п.
считается хорошей практикой делать отбор данных серверной математикой. вывод на морду - кто на чём привык. хоть пхп, хоть джава хоть питон

Psycho писал(а)
Это реализуется через Foreign Key, но ARIA в него не умеет,

Фигня вопрос, XtraDB есть

Psycho писал(а)
Дерево можно строить и по одной таблице

Так и делаю.

Psycho писал(а)
А можно завести в goods
id name
1 Шаверма от Ашота 50 гр.
2 Шаверма от Ашота 100 гр.
3 Шаверма от Ашота 150 гр.
Ключ таблицы goods уникален будет в данном случае

Меня интересует не уникальность ключа, а чтобы наименования одного и того же товара были одинаковыми. И картинки - тоже.

По факту - пишется приложение для ВК, а поскольку ресурсы у меня лично не резиновые, хотелось бы, чтобы пользователи могли добавлять только текстовую информацию - и то в минимальном объёме.

Но если честно, у меня и база толком не спроектирована. Все упущения переделываю прямо в процессе.

Gavrosh писал(а)
запрос ужасен, имхо.

ИМХО, тоже, но главное - по факту он работает.

И что печальнее всего - пока никто ничего лучше не предложил.

Gavrosh писал(а)
просто почитайте про sql ansi 92, архитектуру данных, констрайнты и индексы и т.п.

Простите, тяжёлое наследие FoxPro for DOS даёт о себе знать :-)

Gavrosh писал(а)
считается хорошей практикой делать отбор данных серверной математикой.

PHP выполняется на сервере.
А с выводом на морду данных в формате JSON я уж как-нибудь разберусь.

1. Старая версия.
2. А что там есть такого, что ты реально планируешь использовать ? Зачем усложнять ?

Афраний писал(а)
Но если честно, у меня и база толком не спроектирована. Все упущения переделываю прямо в процессе.

Ключевой момент. Выше критика запроса - потому что ты пытаешься выбрать данные из "базы" которая фактически является в твоем случае набором таблиц, которые построены без учета каких либо механизмов СУБД в принципе.

1. Версии я ставлю из пакаджей, если ставить 10.0.0.38, то желательно переходить на 6.5
2. Да тут как раз наоборот подсказывают, что Aria не имеет нужных функций. И так-то есть до фига чего, что планируется к использованию.

Может и имеет смысл перейти на InnoDB/ XtraDB

Если бы я ещё знал эти механизмы :-)

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

Что я хочу - примерно описал в текстовом файле.
Файл в аттаче.

Афраний писал(а)
ИМХО, тоже, но главное - по факту он работает.

Да, он работает и правильные результаты выдаёт. На тесте, где 10-100-1000 записей и один юзер, даже мгновенно. Если будет прод - это вилы.

Даже хотелки описаны скудно, мягко говоря.
Прямо по файлу:
1. Пользователи - допустим.

>>Подразумевается, что доставка производится в пределах населённого пункта (города)
Я бы не подразумевал, буду исключения 100%.

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

3. У юриков сильно больше требуемых данных, ни тебе КПП, ни отделения банка...

4. Адреса юриков лежат там же где физики выше.

1. Не "допустим", а точно. Я не хочу, чтобы пользователь во Владивостоке себе суши из Калининграда заказывал. Поэтому такое вот программное ограничение. Исключений не предусмотрено.
2. Адреса и вынесены в отдельную таблицу. Строками - ибо классификатор на фиг не нужен. Пусть хоть на остановку автобуса доставку заказывают.
2.1. Номер кошелька ЯД нужен ТОЛЬКО участникам ПЛ и ТОЛЬКО для выплаты вознаграждения ИМ. Владельцы магазинов выбирают свои варианты оплаты, вариант с картой Сбера в списке есть.
3. Нет, этого достаточно. Тем более, 90 процентов продаванов - это ИП Ашота, а всякие КПП при необходимости можно запросить дополнительно, зная дату регистрации и ОГРН.
4. Нет. У физиков город указан индексом главпочтамта, но для юриков точность индекса важнее. Так что там должна быть не только улица и дом, но и город, область край - и правильный почтовый индекс.

Сразу уточню: система рассчитана не на мегаполисы, а на райцентры.
И вот примерный портрет того, для кого это всё и пишется:
vk.com/umangala030218

То, что ниже - считай вода, нет конкретики.

Пойми главное, структура СУБД проектируется под конкретные данные, а у тебя описания кот наплакал даже функционально.

Просто вопросы на вскидку:
Как попадают справочные данные в базу ? (Товары, цены, _остатки_) ?
Как происходит работа с заказами (изменение статуса, изменение состава, отмена, и.т.д)
Структура данных хранения заказа (Более свежие релизы MariaDB например умеют хранить данные в формате JSON, и там много чего для этого добавлено.)
История заказов нужна ? Храним статично (все данные заказа в том же JSON) или собираем запросом по базе (от этого например зависит структура хранения цен, таблица должны быть периодической, с нюансами).
Маркетинговый блок (скидочные карты, промокоды, купоны, прочая херня) ?
От маркетинга спляшет хранение заказов (как храним скидки, или цену без скидки и цену со скидкой, построчно или на чек, как округляем, и.т.д).
Обмены с другими системами?

Вопросов много на самом деле.
Начни с нормального описания по каждому блоку. Потом под каждый блок описание данных и типов и допустимых значений. А потом уже увязывай это все вместе в виде схемы базы.