Что означают поля s.productCategoryId и s.accessoryCategoryId, в чем их назначение в вашей структуре данных?
PS: Чтобы не воевать с синтаксисом ORM, лучше всего задачу разбирать на чистом SQL.
Ваш вариант решения будет выглядеть вот так:
select s.id,
s.title,
s.quantity,
s.productCategoryId,
cl.name as productCategoryName,
a.name as accessoryCategoryName,
s.products,
s.attributes,
s.accessoryCategoryId,
s.accessories
from Scenario s
left Join Category cl on s.productCategoryId = cl.id_category
left Join Category a on s.accessoryCategoryId = a.id_category
where s.id = :id
PPS: Что хотите выбрать?
Несколько разных строк из таблицы Scenario?
Это будет вот так:
...
where s.id in (:id1, :id2)
Несколько строк в диапазоне из таблицы Scenario?
Так:
...
where s.id >= :id1
and s.id <= :id2
Строки из Scenario, которые имеют хоть одно свойство по категориям?
...
where s.productCategoryId = :product_cat_id
or s.accessoryCategoryId = :acc_cat_id
Строки из Scenario, которые которые имеют одновременно два свойства категорий?
...
where s.productCategoryId = :product_cat_id
and s.accessoryCategoryId = :acc_cat_id
... одно из свойств категорий может быть не задано?
...
where (s.productCategoryId is null or s.productCategoryId = :product_cat_id)
and (s.accessoryCategoryId is null or s.accessoryCategoryId = :acc_cat_id)
Если у вас еще есть таблица Tags, которая содержит свойства тегов, например, его наименование, а таблица postTags является промежуточной таблицей для организации связи "многие ко многим", то тут вполне корректно по архитектуре с точки зрения классического реляционного подхода.
Да, запросы к такой структуре могут выглядеть пугающими и они будут не самые быстрые.
Если есть проблемы в производительности, то к дополнению к основной структуре таблиц разработчики могут дополнять архитектуру еще таблицами, которые не нормализованы сильно и используются в качестве кэша (если нужно искать посты, где есть некоторый набор обязательных тегов, то в такой кэш-таблице будет одно поле со всеми тегами для одного поста и используем поиск по строке, либо разбор json, если СУБД позволяет использовать этот тип данных). Кэш-таблицы не универсальны, они заточены под определенный поиск данных и могут быть сильно избыточны по объему.
PS: Для ускорения могут еще использоваться другие инструменты стека приложения, но это совсем другая история.
Поправил решение. Нужен оконный вариант функции count. Если будете испытывать на mySQL ниже 8 версии, то нужен будет велосипед с пользовательскими параметрами, чтобы сделать аналог такой функции.
PS: Прелесть такого решения в том, что group by не нужно прописывать, окно его инкапсулирует по своей сути.
Эта функция нужна, чтобы обрезать начальные и конечные фигурные скобки.
Дано: '{1,2,3}'
Для этой строки порядок действий такой:
1. translate - убираем скобки -> '1,2,3'
2. string_to_array - преобразуем строку в тип данных массив -> [1,2,3]
3. unnest - разворачиваем массив на несколько строк -> первая строка: 1, вторая: 2 ...
4. cast - в каждой строке преобразуем значение колонки в целое число.
Все, теперь можно использовать в SQL.
PS: Если атрибут qualification_documents уже по типу данных является массивом, то шаги 1, 2 и 4 не нужны, куча вложенных функций заметно уменьшится.
Скорее всего, в вашем случае достаточно использовать unnest (добавил решение Б).
sort = sort.sort()
; поставьте в конце, лучше не бросайте операторы без него, даже если JS позволяет это делать.
Когда дописывать код будете, то споткнетесь об эту фичу.
Если это бэкап базы, то нужно взять из файла строки под insert предложением - это данные таблицы (скорее всего это и будет основное "сырье" для парсинга).
Нужно пропускать конструкции, которые реконструируют структуру базы, например, создание таблиц, функций, процедур и т.д.
Как идею решения в лоб можно использовать следующие шаги.
1) Обрабатывать только те файлы, форматы которых могут записывать сведения о прозрачном цвете (gif, png).
2) При загрузке данных текущего файла изображения использовать ту функцию, которая позволяет получить сведения о цвете пикселя с параметром альфа-канала.
3) Пробежаться по всем пикселям изображения и подсчитать число пикселей, которые имеют значение альфа-канала не более некоего фиксированного порога M значения прозрачности.
4) Получить долю (%) прозрачных пикселей по критерию 3 от общего количества пикселей.
5) Если эта доля больше некоего фиксированного порога N (%), то считаем, что в изображении преобладает прозрачный цвет (возможно, он будет фоном, но это не точно).
Узнать, каким способом был создан ключик в процессе установки опции шифрования диска, и собственно, воспользоваться им. Не обязательно, что ключ лежит в учетке MS. https://support.microsoft.com/ru-ru/help/4530477/w...
PS: Не будет ключа - не будет доступа к данным, ничего не попишешь.
Структура у вас такая будет:
1) wall - id, message
2) attachments - id, wall_id, path
где wall_id ссылается на запись таблицы wall.
Проблема в том, что если вы хотите сохранять записи вложений первыми, то вы не знаете какой вставить wall_id.
Есть куча вариантов как это решить.
Вариант 1.
Когда создается сообщение, клиент отправляет сразу и сообщение и вложения.
Тут сложностей со вставкой нет. Сохраняем запись wall, получаем его wall_id, используем для вставки вложений.
Вариант 2.
Мы не можем создать "честную" запись wall сразу, не отправив заранее записи вложений.
Решений варианта 2 первое.
Сохраняем записи вложений с опущенным параметром wall_id, например wall_id приравниваем null.
Когда добавляем запись wall, то известный wall_id вписываем в записи вложений, где было null.
Но учтите, если в вашей системе будет несколько пользователей, то нужно как-то различать, какой пользователь или сеанс пользователя мусорит несвязными записями вложений во время редактирования сообщения.
Для этого в таблице вложений должен использоваться дополнительный атрибут, указывающий на user_id или на его сеанс session_id, так:
attachments - id, wall_id, user_id, path
или так:
attachments - id, wall_id, session_id, path
И при связывании нужно брать не просто wall_id is null записи, а указывать, что брать нужно записи конкретного пользователя или сеанса.
Если пользователь бросил редактирование сообщения без сохранения, и при этом он оставил какие-то несвязные записи, то в вашей системе нужно предусмотреть скрипт, который будет периодически подчищать несвязные записи.
Для определения давно ли добавили записи, чтобы удалять сильно устаревшие, в таблице вложений нужно предусмотреть атрибут даты и время создания вложения. Чтобы можно было легко написать запрос, который подчистит эти старые записи, учитывая их время создания.
Решение варианта 2 второе.
Создаем временную запись wall, как только пользователь запросит форму создания сообщения.
Те же проблемы отслеживания временно созданной записи wall и пути решения такие же как в случае несвязных вложений.
Если у вас повторно используются вложения, то сама задача велит использовать третью таблицу, как вам советовали выше.
3) wall_attachments - id, wall_id, atach_id.
Если нет необходимости повторно использовать вложения, то достаточно атрибута внешнего ключа в табилце вложений.
attachments - id, wall_id, path
PS: наименование parent_id используется, как правило, для ссылки на записи той же таблицы, это для описания древовидных структур подходит.
include предназначен для монтирования выполняемого кода php, а не для данных.
У вас скорее всего проблема развязать логику отдачи файла от штатной выдачи контента обычной страницы.
Если не получается, то выдачу файла нужно вынести в отдельный php-скрипт.
Например, в index.php у вас генерация HTML, а в download.php - отдача файлов клиенту.
Подключать download.php каким либо образом к index.php не нужно, нужно клиенту обратиться к нему по url в браузере:
имя_вашего_сайта/download.php
Если вы пытаетесь сконструировать содержимое файла как HTML, то имейте ввиду, что чтобы Excel воспринял содержимое, нужно руководствоваться как минимум нотацией XML.
Чтобы посмотреть пример генерации такого файла, в MS Excel сохраните файл как "Таблица XML 2003".
Откройте скачиваемый файл в блокнотоподобном текстовом редакторе и посмотрите в начале файла, что там есть помимо бинарных данных. Возможно, php отдает не только тело файла, но и какое-нибудь предупреждение.
PS: Чтобы не воевать с синтаксисом ORM, лучше всего задачу разбирать на чистом SQL.
Ваш вариант решения будет выглядеть вот так:
PPS: Что хотите выбрать?
Несколько разных строк из таблицы Scenario?
Это будет вот так:
Несколько строк в диапазоне из таблицы Scenario?
Так:
Строки из Scenario, которые имеют хоть одно свойство по категориям?
Строки из Scenario, которые которые имеют одновременно два свойства категорий?
... одно из свойств категорий может быть не задано?