Почему вы считаете, что система в основе которой не лежит субд сможет быстрее давать результат на огромных базах, где быстрые выборки на основе построения специализированных индексов и прочих субдшных фишек быстрого извлечения информации хуже вашей файловой реализации? Может быть просто вы не задумывались еще об этом?
Потому, что вы считаете мою систему чистой воды базой. Но это не совсем так. Это система гибридная и она предназначена (в перспективе) под решение разнообразных задач, которые в своем базисе имеют несколько констант, которые, уверен, будут всегда, пока существует процесс альт линукс.
И почему практичный и весьма универсальный подход основанный на json для загрузки на сервер информации и который обладает простотой и наглядностью исполнения практически в любых современных реализациях - ни к чему, а применяемый подход у вас гибче?
Хотя бы потому, что код клиента меняться будет не сильно, протокол обмена меняться не будет. Может быть лишь увеличение количества информации для сбора и основная работа будет на серверной стороне (что в случае тонкого клиента и должно быть). Универсальность выдачи информации сокращает раза в два количество необходимого кода (как мне кажется). При этом всякие навороты вроде диаграм и графиков можно доделать позже.
Если вас терзает json и субд, то вам никто не мешает сделать лучше и быстрее. Я же вам не мешаю делать вещи и не влезаю со своими советами, потому что для меня прерогатива творчества незыблема. Инструментарий уже вторичен в этом смысле.
Я спрашиваю как раз пояснить в чем там недостатки? Что в подходе не так? В чем неправильность назначения?
Всё так для их целей и задач (как я их понял по косвенным признакам). Для тех целей, которые я закладывал, эти решения не совсем подходят (хотя в чём-то они кажутся проще, но устойчивость к вышибанию данных из базы в моем случае выше априори, т.к. в случае повреждения файла базы и без наличия бэкапа данные извлечь без вспомогательных инструментов будет непросто, в моем же случае вся оставшаяся без повреждений база остается невредимой и доступной тут же не отходя от кассы). Это может показаться мелочью в современных реалиях, но я это сознательно закладывал архитектурно в самом начале. Также закладывался принцип минимума внешних зависимостей, в том числе и от самого php интерпретатора, максимальное использование базовых вещей, которые идут в любом дистрибутиве альта. Другими словами, вновь и вновь вы видите, что подход и цели другие, что накладывает отпечаток на используемые решения.
Может быть поэтому я отличаюсь от "современных программеров", которые отталкиваются от решений решений (типа бэкапа баз штатными средствами, делая реверанс в сторону универсальности применяемых шаблонов). Отчасти поэтому мы имеем с софтом то, что имеем. Когда продумывать архитектуру не надо - мощностей ведь много и они дешевые в массовой статистике. Современное железо отучает думать стратегически, может быть и не всегда, но в массе своей это так за исключением некоторых направлений, где условия более жесткие и по-другому просто нельзя.