В некоторых ситуациях - нет. Не экономит. Особенно, если это крупное приложение, где нужно продумывать интеграционные тесты.
К слову, вы предвзяты к тестировщикам. Они работают, реально работают. Мой знакомый тестировщик весь рабочий день пишет эти тесты, чтобы ничего не сломалось на проде. Фактически, весь функционал рабочего сайта описывает именно он. И кроме того, вся автоматизация, когда нужно покрыть не менее 98% кода тестами (это реальный кейс), сделать интеграционные и функциональные тесты, сделать так, чтобы это все работало на коммитах, чтобы перед сборкой все прогонялось на проде. Все это требует сил, времени и денег.
Хотите, чтобы работало без ошибок - платите тестировщику.
Lander, лично я не против использования ORM. Наоборот, всеми руками за. Я говорю про конкретно этот вопрос. Не знаю, для чего автору это потребовалось, но видимо он знает.
Максим Федоров, Только это ORM, а не query builder. И он требует установки и не возвращает готовую строку.
А автору просто следует подучить SQL, потому что составить запрос к базе данных, обычно, не составляет труда и искать для этого отдельное ПО - глупость. Есть шикарный онлайн-справочник для этого.
rsoinvi, посмотрите, как это сделано в bootstrap 4.
Есть вариант сделать еще один блок, который займет оставшуюся ячейку. Но это костыль.
Правильно задавать маргины для блоков, а не использовать space-between.
Денис, это и есть подход из боевых условий. Реально работающая модель та, которая предполагается самим устройством баз данных. То, что вы задумали - избыточно.
Большие объемы фиксятся добавлением индексов, шардингом и тому подобным безобразием, хотя на реляционных базах данных шардинг немного болезненный.
Денис, Пожалуйста. У вас уже есть таблица-посредник. Списания - уменьшение значения одного столбца (при желании создается один столбец, который дублирует изначальный приход). Приход - добавление новой строчки.
Пример списания:
UPDATE items SET amount=amount-1 WHERE id=3;
Пример прихода:
INSERT INTO items (`колонка`, `колонка`) VALUES (`значение`, `значение`);
Пример извлечения остатка:
SELECT amount FROM items WHERE id=3;
Плюс повесьте триггер на событие update таблицы ITEMS, которое будет писать в таблицу ITEM_SELLS, какой конкретно товар продали, кому и когда, если это критично. Если нет - забейте.
Я даже добавлю.
Здесь вполне может быть дело и в оптимизации скрипта. Вы пробовали запустить xDebug и посмотреть количество памяти и системных вызовов по нему? А что у вас с конфигурацией php, apache? Вопрос а-ля "у меня вроде где-то живот болит, но ничего конкретного сказать не могу, скажите, как лечить?"
