Евгений Вольф

В таблице ставок нет уникального индекса на item_id+price.

Почему?

С виду кажется, что нужно просто прописать уникальный валидатор в модель ставки для валидации пары значений item_id + price

Лично мне - так не кажется.

Есть ли возможность в Yii2 предотвратить вставку одинаковых значений

Эта возможность должна быть в БД, а не в Yii2, чисто логически.

при одновременной посылке одинаковых запросов, обе проходят валидацию

А как Вы одновременно генерируете одинаковые запросы? (просто интересно)

Варианты?

1. Добавить UNIQ-индекс и не изголяться
2. Блокировки

Можно, и тут вопрос даже не в PHP, практически на любом языке можно (на любом, который умеет работать с MySQL).

Синтаксис команды CREATE DATABASE.

Для этого в Eloquent (и не только) существуют связи, в Вашем случае - один ко многим, т.е. одна сумка -> много фотографий.

P.S. Eloquent - это такая очень удобная штука, встроенная в Laravel, для работы с данными из БД, в т.ч. позволяющая быстро настраивать связи между объектами.

----------

Ещё есть вариант сделать это прямо на уровне SQL-запроса, для MySQL выглядеть будет примерно так:

SELECT service_category.*, GROUP_CONCAT(service.id SEPARATOR ',') AS ids
FROM service_category 
LEFT JOIN service ON service.category_id = service_category.id
GROUP BY service_category.id

В данном примере, таблица service ссылается на таблицу service_category через поле service.category_id. В качестве результата получаем вот такой дополнительный столбец, где перечислены все "service"ы для текущей категории (их ID) с разделителем через запятую:


UPD. Тот запрос который у Вас в примере - это НЕ Eloquent, это QueryBuilder.

Если это то, про что я думаю - Вы можете:
1. Скачать и установить MySQL Workbench (официальную программу от разработчиков MySQL)
2. Прямо в ней посмотреть/создать/что-то-ещё диаграмму, как на картинке по первой ссылке

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

Файл /config/database.php, строка 53: 'strict' => true, (в "разделе" 'mysql'), значение поменять на false.

Подробности:

Откровенно говоря, не совсем понятно чего Вы хотите добиться... Вернее, в чем именно проблема?

При POST запросе первым делом удалять все данные по id студенту/предмету и потом записывать данные с запроса (получается 2 операции). В таком случае при неудачной записи данных, можно потерять все предыдущие данных об оценках, я думаю.

Что бы ничего не потерялось "при записи" - есть "транзакции" (рекомендую с ними ознакомиться", но вкратце, суть такая - что либо операция будет выполнена полностью, либо она не будет выполнена вообще, т.е. произойдёт "откат" до того состояния, в котором данные были до начала транзакции).

Заранее создать "пустые" записи без оценок в таблице для каждой даты с 1/09 по 31/05 (учебный год, 270 дней где-то). Но возникает проблема с оптимальностью использования БД, думаю пустых ячеек с оценками не должно быть.

Я думаю так же (что пустых записей [про какие ячейки идёт речь - я пока не понял]) - быть не должно. Ещё я думаю, что плодить колонки в БД - тоже плохое решение, если в них нет реальной необходимости. MySQL (как и многие другие) поддерживает механизм "реляций" (по русски - "связей"), то есть позволяет связывать одни данные с другими и контролировать целостность (корректность) таких связей. То есть, Вы можете связать воедино многомерную модель данных, например студента, предмет, преподавателя, дату, оценку и так далее, при том, что предметы хранятся в одной таблице, преподаватели в другой, оценки с датами в третьей (и т.д.) а их совокупности - в N'ой (в данном случае, в 4-ой) таблице.

Как уже верно заметил г-н. TheLostRoot, не стоит ориентироваться на кол-во операций, Вы пытаетесь оптимизировать что-то, но не с той стороны. Если у Вас много данных которые вставляются (хранятся), но доступ к ним осуществляется редко - есть специальные архивные таблицы, если Вам не нужен контроль целостности, связи, транзакции и т.д., а нужна скорость - есть MyISAM таблицы, если у Вас сервер не выдерживает нагрузку - есть такая штука как "мониторинг ресурсов" с целью выявления узких в его производительности, есть репликация и так далее.

Оптимизируют обычно сложные запросы, в которых участвует множество таблиц/данных, а не простые INSERT/UPDATE/DELETE'ы. Проблема не в количестве операций как таковом (к тому же, при DELETE - физически данные с диска не удаляются, а отмечаются как "удаленные" [в MySQL и не только]), а в их "сложности" и производительности. Иными словами, не пытайтесь решить проблемы подобного рода "заранее", т.к. они возможно не настанут вообще никогда, гораздо разумнее правильно спроектировать БД, чем "нагородить огород" и "сэкономить 1 (условную) операцию". Ну и не забывайте про то, что InnoDB и его аналоги (а так же некоторые другие типы таблиц в MySQL) поддерживают транзакции.

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

Почему при соединение с базами данных phpmyadmin выдает такую фигню?

Возможно, по тому, что вот эта функция:

$result = mysqli_query($connection, 'SELECT * FROM `articles_categorie`');

требует первым параметром "mysqli_connect()", а не "mysql_connect()" как у Вас?

Здравствуйте!

Здравствуйте!

имеет ли смысл создать вторую таблицу, но только с теми данными которые будут часто доставаться

В MySQL - да, в PostgreSQL возможно, я порекомендовал бы Вам использовать для этого наследование. НО! крайне важно понимать, что смысл таких операций есть только в тех случаях, если Вам действительно нужно увеличить производительность, то есть, производительности на данный момент, по какой-то причине не хватает (и никаким другом способом или в виду неких соображений, её увеличить нельзя) и Вам нужно её увеличить. В иных случаях, плодить лишние связи, крайне не рекомендуется. Не зависимо от того, MySQL это либо какая-то иная БД.

*из личных наблюдений: чем меньше таблица в MySQL (в плане объёма на диске) - тем быстрее выборка, не зависимо от того, участвую ли "лишние" поля в этой выборке или нет.

И если да, то лучше использовать MyISAM или InnoDB?

Быстрее - MyISAM, надёжнее (+ там ещё транзакции всякие поддерживаются, и прочие плюшки) - InnoDB. Лучше - ?.

как сделать запись в одну таблицу сразу же после выполнения записи в другую таблицу?

Наверное, с помощью триггера или транзакции. Не понимаю суть Вашего вопроса.

При этом нужно знать сохранить один и тот же айдишник у них.

Для этого есть LAST_INSERT_ID().

можно создать таблицы в существующей?

Если в существующей, то она никак не замедлит работу остальных таблиц?

Особо никак, т.к. таблица - это файл(ы) на диске, обычно 1 таблиц - это несколько файлов. И если Вы к ней обращаетесь, то "замедлит работа" она точно так же примерно, как и все остальные файлы на диске (если не бросаться в крайности).

mysqli_result Object

Это судя по всему, не результат, а объект результата или указатель. Примерно это должно помочь.

P.S. Извиняюсь, ссылкой промахнулся. Исправил.