alexalexes

Вариант 1. Если надо проверить одно единственное булево выражение и что-то вывести, не отходя от склейки строки:

td>".($row["ID_EMPLOYEE"] ==1 ? "первое значение" : "второе значение")." </td>

Вариант 2. Когда у вас возможна более толстая логика вывода в каждой ветке if:

echo 'Перед if прекращаем шлепать HTML закрывающейся кавычкой и точкой запятой';
if(условие)
{
  echo 'Шлепаем HTML по истине if-а';
}
else
{
  echo 'Шлепаем HTML по ИНАЧЕ';
}
echo 'Продолжаем шлепать HTML';

Если возвращается идентификатор файла - тип integer.
Если возвращается полный путь к файлу или его url - тип string.
Если возвращаются бинарные данные содержимого файла - тип string.
Если возвращаются raw данные из буфера ob_* вместе с http заголовками и телом файла - тип string.
Если файл открыт файловой функцией и берется ее указатель - смотрите какой тип возвращает эта функция для указателя.

Учет подключенных устройств bluetooth осуществляется на уровне приложения выше драйверов донгла. В каких-то случаях ОС использует свою утилиту, в каких-то случаях можно использовать утилиту от производителя донгла (или может быть универсальная утилита). Сам донгл учетных данных не хранит.

При наличии параметра uri страницы, контекст ресурса можно получить так:

$page = $modx->findResource($uri);
$context_key = $page->get('context_key');

В вашей структуре данных будет как минимум 3 схемы хранения данных, отвечающие за разные подсистемы:
1. Схема для подсистемы управления учетными данными пользователей
Подсистема отвечает за регистрацию пользователей, аутентификацию. То есть, позволяет пользователю при предъявлении своего токена (логина и пароля), как-то соотнести его с учеткой в системе. Или помочь восстановить доступ к этой учетке.
2. Схема для подсистемы прав доступа
Перечисленная структура таблиц позволяет создать шаблон роли пользователя с заранее оговоренными допустимыми действиями над определенными типами задач. И применить шаблон роли на пользователе - создав роль пользователя.
Данные из этой подсистемы позволяют проводить авторизацию пользователя, ограничивая его область привилегий.
Для этой подсистемы нужно уточнять требования, чтобы понять насколько вам нужен шаблон ролей, какие свойства в него должны входить и т.д. От этого будет зависеть структура таблиц.
3. Схема для подсистемы планировщика задач
В этой подсистеме можно создать шаблон задачи, назначить номинальных куратора и исполнителя (пока что по одному пользователю, если нужно больше, то расширяйте это таблицами со связями многим-ко-многим).
Есть возможность назначать задачу на конкретный календарный период (и не один раз) - с указанием фактических куратора и исполнителя (тоже по одной единице - надо больше расширяйте структуру таблиц). Наличие таблицы календарного планировщика позволяет зафиксировать параметры выполнения задачи во времени, если в ней будут непредвиденные изменения в кураторах и исполнителях, перенос на другое время.
Нужно определиться как генерировать задачу для таблицы-календаря - заранее накидать фактические даты выполнения на неделю, месяц, год, и потом их корректировать по обстоятельствам, или назначать следующую дату выполнения после истечения периода выполнения предыдущей.
Схема таблиц позволяет любой из этих вариантов.
Также из задач можно построить дерево задач и нанести каждую подзадачу в планировщик (есть связь таблицы по родителю).

4. Можно сделать схему подсистемы построения отчетности как по шаблонам задач, планировщику, так и по назначению прав доступа, кураторов, исполнителей.

----------------------------------------
Схема таблиц учетных данных пользователей

Пользователь
#* Код человека
*Дата регистрации
* ФИО
*Адрес электронной почты
* Хеш пароля

-----------------------
Схема таблиц прав доступа пользователей

Шаблон роли пользователя (модель роли)
#* Код шаблона
* Название роли

Действия прав доступа (справочник)
1. Код действия
2. Название действия (просмотр, назначение, отмены, удаления, переноса задачи, редактирования шаблонов задач, редактирования планировщика задач)

Cвойства шаблона прав доступа
1. Код свойства прав доступа
2. Код шаблона роли
3. Код действия прав доступа
5. Код типа задач
4. Дата создания свойства

Роль пользователя (реализация роли пользователя)
1. Код прав доступа пользователя
2. Код шаблона роли
3. Код пользователя

------------------
Схема таблиц планировщика задач пользователей

Тип задачи
1. Код типа задачи
2. Название типа задачи

Шаблон задачи (модель задачи)
1. Код шаблона задачи
2. Код типа задачи
3. Код родителя шаблона задачи (на сущность Шаблон задачи)
4. Наименование задачи
5. Описание задачи
6. Дата создания шаблона
7. Периодичность выполнения
8. Код пользователя (номинальный куратор)
9. Код пользователя (номинальный исполнитель)
10. Дата назначения номинального куратора
11. Дата назначения номинального исполнителя

Календарь задач (реализация задач, он же планировщик)
1. Код элемента
2. Код шаблона задачи
3. Дата начала выполнения задачи
4. Дата окончания выполнения задачи
5. Код пользователя (фактический куратор)
6. Код пользователя (фактический исполнитель)
7. Дата назначения фактического куратора
8. Дата назначения фактического исполнителя
---------------------

PS: Можете из этого перечня таблиц и их атрибутов нарисовать DFD диаграмму или диаграмму по Ричарду Баркеру. Правда, тут не обозначены явно связи, но можно догадаться по названию внешних ключей, как связаны таблицы.