rPman

Как это ни странно, но несколько запросов вместо одного большого, хотя и отработают в результате дольше, но повышают эффективность утилизации ресурсов и увеличивают способность базы данных к масштабированию, в т.ч. за счет нескольких серверов. Т.е. при одних и тех же ресурсах (процессор/память/диск), если сравнивать две такие разные реализации, в общем сумеют обработать больше запросов (итоговых страниц) та где много отдельных запросов.

Плюс, отделяя комментарии от основного поста, будет проще расширять функционал и наполнение атрибутами., ведь это совершенно разные сущности, даже если сейчас на начальных стадиях развития проекта у них похожие поля. А еще, кто сказал что комментарии нужно загружать вместе с постом? Кто сказал что их нужно загружать сразу все? достаточно знать их количество (в идеале оценку по высоте страницы для их отображения) и подгружать по мере просмотра (вопрос только про поиск на странице, но и его можно перегрузить), такой подход может значительно разгрузить сервер, когда пользователи начнут работать с постами с сотнями и тысячами комментариев, грузить их все всем просто глупо.

Дублируй, это не недостаток, а прямое следствие оптимизации

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

Необходимо всеми способами избегать того что пользователь выбирает что то из списка размером больше 10 элементов (в редких случаях несколько десятков но никогда сотни и выше) и давать больше возможностей по предварительной фильтрации (например по первой букве) и даже предлагать варианты, например на основе предыдущих запросов

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

У тебя должно быть поле, которое позволит определить однозначный порядок записей (дата у тебя не уникальна значит не подходит), например id с полем autoincrement (осторожно, некоторые базы не гарантируют что значения будут гарантированно расти).

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

Если будет такое поле (id таблицы или сразу значение твоей второй колонки), то запрос, выдающий что тебе надо будет очень простым и отрабатывать очень быстро

select date,val from table where val<>prev_val order by id

p.s. иначе тебе придется на каждое значение искать его предыдущее вложенным запросом через order by limit или max/min limit что не очень быстро

select date,val from table x where val<>(select val from table y where y.date<x.date order by id desc limit 1)

спецы могут посоветовать красивее запрос через left join, я считаю нужно избегать таких случаев когда нужно искать соседнюю запись
вот посмотри как я решал похожую задачу

У криптовалют типа bitcoin (не etherum) именно так и реализовано - баланс на аккаунте пользователя это сумма не потраченных выходов, т.е. буквально каждый входящий перевод (сдачи от исходящих)

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

Кстати, в этой модели способов сформировать один и тот же по сумме перевод может быть несколько (можно брать разные входящие переводы), и можно (судя по всему твоя задача именно такая?) можно формировать лишние выходы, например по каждому входу от разных пользователей создавать точно такое же количество (или объединять по пользователю) выходов.
------------------

Формально, у тебя матрица, столбцы и колонки - это пользователи, а ячейки - текущий баланс, полученный от соответствующего пользователя. Можешь использовать эту модель, но историю придется так или иначе сохранять, причем в зависимости от целей, ее можно сохранять в каждой ячейке (например чтобы восстанавливать всю матрицу на момент времени в прошлом)

Ты неправильно создаешь csv, строки в валидном csv могут содержать \n и разделитель (дублируется), используй штатную функцию fputcsv, записывающую строчку в файл (аналогично читать fgetcsv)

Для json потоково одним проходом не получится, не зная структуры этих json для csv нужно будет два прохода: первый - определяет все возможные колонки (и если надо сохраняет значения), а второй - заполняет массив строки (для передачи fputcsv) пустыми значениями для тех колонок, значения которых отсутствуют. Чтобы порядок был верный первый проход должен сформировать массив - список названий колонок, а второй проход в цикле формирует массив пробегая по этому массиву названий колонок.

p.s. а у тебя в json точно только один уровень? если есть вложенности на это нужно проверку делать и как то реагировать

Вот этот список/таблица в которой номеру соответствует строка-описание называется справочник
У тебя 2 основных подхода, хранить эту таблицу в базе данных (особенно если приложение должно уметь его редактировать) либо хранить его на клиенте и подставлять в программе

Про хранение на клиенте тебе уже подсказали

Про хранение в базе данных - либо ты создаешь буквально таблицу-справочник, либо про создании таблицы (твоя profile) определить не числовое поле а enum со строковыми описаниями (подходит для очень небольшого количества записей)

При использовании таблицы-справочника sql запрос будет примерно таким

select ... from profile p left join admin_cls a on p.admin=a.id

понять задание сложно, информации мало, нужны примеры данных с пояснениями

applications.back_date скорее всего содержит дату погашения задолжности, значит если она null то applications.customer_id ее будет ссылаться на должника? вот и считай эти count(applications.id) для group by applications.customer_id с условием applications.back_date is null

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

select .. from ... where ... and (:product_group is null and `product_group` is null) or (`product_group` = :product_group)

чтобы один и тот же параметр в запросе использовать несколько раз, используй пользовательские переменные (живут до конца сессии), т.е. выполняешь два запроса, первый
set @product_group=:product_group
а уже в самом запросе вместо :product_group используешь @product_group

Формат csv для данной задачи наиболее неподходящий, теряется информация о структуре, особенно когда на очередной строчке количество колонок меняется и еще страшнее - если не меняется, что там лежит, что в какой колонке - не известно, машина не прочтет а человек обматерит изобретателя этого бреда.

Вторая проблема - денормализация, вот это объединение записей. Причина простая - реляционные базы данных по определению не хранят достаточно информации для понимания, чем является данные. В некоторых случаях можно что то вытащить из типа индексов (fk и pk) и ограничений constraints но в общем нет. Как понимать связь М-1-М? какую таблицу брать за базовую а какую второстепенной, т.е. что выбирать left join, right join или inner join? Да, для простых справочников, когда таблица является лепестком в графе связей 1-М можно 'смело' связывать такую таблицу, дублируя данные справочника по foreign key индексам, но опять - зачем? ведь при чтении уже не будет видно что использовался справочник.

p.s. Я могу предположить что конечная цель у автора - работа со случайными данными (много мелких проектов, написанных разными людьми с сильно оотличающимися подходами к разработке и способам хранения данных) и извлечение из них осмысленных, к примеру в заранее определенном формате
Когда то давно у меня в дипломной или рядом была проект, в котором в качестве доп инструмента была простая самописная утилита, ее натравливаешь на очередную базу с неизвестной структурой, она проводила простенький анализ структуры и выдавала в интерфейсе таблицы поля и показывала короткий брифинг по каждому выбранному полю (тип связи и пример данных там хранящихся), цель утилиты - указать таблицы и поля, из которых дальше будет извлекаться данные (т.е. дать интерпретацию этим данным). Без этой утилиты работа по определению какое поле чем является достаточно муторная, в имеющихся приложениях по работе с бд нужно много кликать, запускать хоть и заранее написанные запросы и т.п. Может вам лучше это состряпать? Я искал и не нашел, готовые универсальные решения слишком сложны (а смысл в простоте интерфейса).

в c# есть унифицированный инструмент по подключению к базам данных - ado.net (вся возня - в построителе connection string, плюс таскать с собой по больше драйверов от разных бд), плюс есть системный odbc (уже устарел но для старых баз данных это иногда единственный способ подключения) для которого есть поддержка ado.net

select ... from ...
union
select ... from ...
union 
...

выдаст уникальные строки, если использовать union all то нет

В ответах все правильно сказали, но не дали собственно решения, вот оно:
заведи поле num, в котором будет размещаться порядковый номер записи, при запросе записей делай group by num

при каких то модификациях порядка (удаление или например вставка в середину порядка записи) делай номер с половинкой (например вставить запись между 3 и 4, то num пусть будет 3.5) и обновляй порядок

update table set
num = ROW_NUMBER () OVER ( ORDER BY num ) RowNum
...

кстати вместо половинчатых номеров можно сначала сдвинуть все номера больше нужного (например вставить 3-им, добавляешь условие where num>3 а потом вставлять.

Зарос выглядит правильным, значит что то с данными не так.

Посмотри что выводит запрос если оставить только одно условие к примеру по street? и выводи в select *

Майкрософт офис позволяет делать загрузку данных на страницу по запросу в sql базу данных, в экселе там для этого есть целый gui - data connection wizard.

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

Программировать в экселе невероятно просто и сложно одновременно. Сложно - даже уже знакомому с программированию некоторые вещи там реализованы странно и неудобно. Просто - потому что есть готовый генератор кода - ты нажимаешь кнопку - старт записи макроса, затем делаешь действия клавишами мышкой и прочими, затем жмешь - остановить запись макроса и смотришь cгенерированный код (даже такие команды как сохранить файл как). Этот подход позволяет понять, какой код нужно делать на какие действия, практически без копошения в неудобной документации.

К тому же скорее всего понадобится автоматизировать только механизм сохранения отчета в документ, отвязанный от базы данных. Тупее всего - сделать в шаблоне 2 страницы, одна пустая - куда будет копироваться результат, другая - шаблон с логикой и настройками подключений, откуда будет копироваться результат на первую, затем исходная страница удаляется, и документ сохраняется под нужным именем.

Итого, задача построения отчетов будет сводиться к правке нужных параметров отчета в базе данных (консольные утилиты oracle для выполнения скриптов например либо из той же программы на excel, так как там в макросах можно делать полноценные формочки с кнопочками), каким то образом указанию имени файла для сохранения результирующего отчета и открытию файла-шаблона.

p.s. автоматизация работы с excel макросами для неофитов выглядит как магия - открывается документ, в нем прямо на глазах начинают появляться данные сохраняться и открываться новые файлы (да эксель невероятно медленный, на столько что это видно человеку).