Иван

$query="SELECT a.*, GROUP_CONCAT(DISTINCT b.subject_id) AS subject
FROM `USERS` AS a
LEFT OUTER JOIN `USERS_SUBJECTS` AS b ON a.id = b.user_id
WHERE a.id ='$id' GROUP BY a.id";

Мог ошибиться - свой запрос "прилаживал". У меня была недавно аналогичная задача.... Он конкатенирует в строку значения из таблицы users_subjects - потом explodом можно получить массив...

Поищите join concat mysql

Вообще надо использовать все варианты.
Те запросы, чьи результаты не требуют реалтайм проверки можно кешировать. Для сложных ситуаций можно и руками написать. Еще рекомендую поискать, как в вашей ORM делается жадная выборка. Такая фича позволяет большинство (не все, но очень многие) запросов не дергать по одному, а объединить в один большой.

Тут нет серебряной пули. Берете профилировщик, находите самые медленные места и думаете, какой из этих подходов подходит тут чуше всего. Реализуете его. И так дальше по списку.

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

Таблица концептов(concept):
ID | NAME
200 | Параметры отправки почты
300 | Параметры отправки заданий
....

Таблица параметров(param):
ID | CONCEPT | NAME
1 | 200 | Отправлять в пн
2 | 200 | Отправлять во вт
3 | 200 | Отправлять в ср
...
10 | 300 | Отправлять задание 1
11 | 300 | Отправлять задание 2
12 | 300 | Отправлять задание 3
...

Таблица Пользователей(users)
ID | NAME
1 | Саша
2 | Петя
3 | Вася
...
Таблица реальных значений(xval)
ID | CONCEPT | USR_ID | PARAM_ID | VALUE | ACTUAL
1 | 200 | 1 | 1 | 1 | 1 | - Отправляем Саше по понедельникам почту
2 | 200 | 1 | 2 | 1 | 1 | - Отправляем Саше по втоникам почту
3 | 200 | 1 | 3 | 1 | 1 | - Отправляем Саше по средам почту
4 | 200 | 2 | 3 | 1 | 1 | - Отправляем Пете по средам почту
5 | 200 | 3 | 2 | 1 | 1 | - Отправляем Васе по вторникам почту
...
20 | 300 | 1 | 10 | 1 | 1 | - Отправлять Саше задание 1
21 | 300 | 1 | 11 | 1 | 1 | - Отправлять Саше задание 2
22 | 300 | 1 | 12 | 1 | 1 | - Отправлять Саше задание 3
23 | 300 | 2 | 11 | 1 | 1 | - Отправлять Пете задание 2
23 | 300 | 3 | 10 | 1 | 1 | - Отправлять Васе задание 1
Запрос

select 
  u.name as usr,
  p.name as pname,
  x.value as val
from users u 
left join xval x on x.user_id = u.id and x.concept = 200
left join param p on p.id = x.param_id
where u.id = 1

вернет вам все параметры отправки почты (concept=200) для Саши.
USR | PNAME | VAL
Саша | Отправлять в пн | 1
Саша | Отправлять во вт | 1
Саша | Отправлять в ср | 1
Нужно узнать, какие конкретно отправлять задания?
Просто меняете концепт на 300 и результатом будут все задания на отправку для Саши.

Добавить какой-то параметр? Просто добавляете строку в таблицу и все!
И никаких правок структуры в продакшене и другого геморроя.

масштабирование этих настроек (I want to believe) не планируется и вроде как можно сделать жестко.

Очень надеюсь, что опытные архитекторы, или те, кто имел дело с подобным, подскажут как быть.

Не верьте, и масштабирование будет и изменения (разве что, количество дней недели не поменяется в ближайшее время). Поэтому, позаботьтесь о себе сейчас - сделайте гибко.

Алгоритм прост:

1. Делаете максимально удобное в плане доработки решение
   
2. Пользуетесь
   
3. Собираете фидбек
   
4. Формулируете список изменений, используя в качестве обоснования конкретные проблемы текущей реализации
   
5. Переходите в начало цикла
   

Обратите внимание, что алгоритм подразумевает, что вы сами решаете, что именно в вашем случае означает "удобное в плане доработки".
Здесь есть два полюса:

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

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

Понятно объяснили.
Просто добавьте внутри класса свои свойства.
К примеру

<?php
//Не забудьте о неймспейсах
//...
class User extends ActiveRecord
{
public $test;
//остальной код...
}

Таким образом вы сможете записывать и брать данные с test. Кстати, можно и записать потом "test" у валидаторы, в attributeLabels и прочее.
Единственное отличие - они не сохранятся в базу данных (так как некуда), и уже после валидации или сохранения об этих данных нужно подумать самому.

Можно сгенерировать поле автоматически с помощью переписывания метода afterFind() (почитайте документацию). На счет сортировки могут быть тонкости, но насколько я понимаю, все должно быть довольно хорошо, правда придется расширить класс сортировки и указать его поведение при использовании этого свойства. Для этого почитайте документацию по объекту сортировки \yii\data\Sort

Наверное, стоит лучше использовать партиционирование вместо ручного биения по таблицам

Я пробовал всё вышеперечисленные в других ответах, но как-то книги не давали достаточно практики. В конечном итоге полное погружение и скачёк из теории в практические навыки с последующим постоянным применением в работе мне дал вот этот (уже ставший легендарным) курс: https://class.stanford.edu/courses/Engineering/db/... (курс регулярно повторяется, доступен для изучения в собственном темпе и есть в записи на трекерах).
После него берёте любую более-менее адекватную книгу по специфике MS SQL и считаете навык у Вас в кармане.

По любому начинаем с Мартина Грайбера "Понимание SQL" - идеальная книга для начального изучения.

Зависит от контекста. Для современных браузеров подойдёт решение с CSS3 единицами 'vh';
Для старых браузеров придётся задействовать javascript и отслеживать высоту экрана.
caniuse.com/#feat=viewport-units - первый вариант, height: 100vh соответствует высоте окна браузера.
https://api.jquery.com/height/ - второй вариант, $(window).height вернёт высоту окна браузера.
По первому варианту:

#hei {
    height: 100vh; /* 100vh - 100% от высоты viewport(окна браузера) */
}

По второму варианту:

function setHeiHeight() {
    $('#hei').css({
        height: $(window).height() + 'px'
    });
}
setHeiHeight(); // устанавливаем высоту окна при первой загрузке страницы
$(window).resize( setHeiHeight ); // обновляем при изменении размеров окна