Вопрос о php, js и mysql

Можно же и много строк в одном файле хранить.

Если данные однородны, то следует их писать в базу, разбирая JSON на объекты. Тогда будет экономия по времени извлечения и по объёму данных. Если же там неоднородное месиво, тогда, на мой взгляд, можно рассмотреть и вариант с хранением в файлах.

Спешу подогреть вашу паранойю, так как многие кодеры активно интересуются, как сделать перехват и изменение строки JSON https://myht.ru/question/34654139-perehvat-i-izmenenie-stroki-json-do-togo-kak-jque Соответственно это можно реализовать, да любую БД можно хакнуть. Если переживать об этом постоянно, то с ума сойти можно.

Вообще вы как-то поверхностно описали проект и проблему в целом. Почему вы считаете. что в обязательном порядке кому-то понадобится подделать JS и генерировать JSON с вредоносным кодом? Были предпосылки?

OkoloIneta, Вот оно и видно что вы Около Нета! Не несите ахинею вместе со ссылками непонятно про что

Можно. Но мне потом надо экспортировать данные, делать по ним поиск.

Что имеется под однородностью?

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

Мой опыт показывает, что 100к вполне рабоче, правда не на хостинге конечно, а внутри VPS.

Ну и конечно, лучше не в 1 папку сувать, а в несколько, это обычно не проблема.

Вот более 100к уже больше проблем. Более 1 млн надо уже думать серьезно.

Экспорт зависит "какой". Если вы не планируете пользоваться индексами от базы один вред.

Если планируете, то предстоит вначале верифицировать ваши данные, затем уже в базу загонять в нормальном виде с разбивкой по полям итп.

Сувать туда просто текст смысла ноль.

ЗЫ. Файловая система - это такая база данных с доступом по имени-пути... вероятность того, что sql субд будут работать в этом применении быстрее стремится к нулю. Для большого кол-ва фалов есть кстати какие-то отдельно типы файловых систем... вроде бы еще быстрее.

Все верно, размер списка файлов в каталоге -4к по умолчанию. Если список файлов больше - повод раскидывать по суб-каталогам, так как начинает падать производительность.

Набор свойств известен. Но я не хотел записывать каждое свойство в отдельную ячейку mysql именно по причине того что большой шанс что при попытке взлома мне могут залить левые данные. А значит нужно дополнительно делать проверку всех свойств JSON.

Я предполагал таблицу, в которой есть 2 значения = id и JSON в 2 ячейке.

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

Ну почему? данные то будут в оперативе, а при чтении с диска будет медленее.

Если бы вопрос стоял именно так, то никто не пользовался бы MySQL, потому что эта проблема была бы у всех. Однако весь мир как-то хранит данные в БД.

С чего вы взяли, что кеширование в памяти для базы будет лучше, чем для диска ?

В любой нормальной ОС ВСЯ свободная память кеширует операции с диском.

Если хотите работать "быстро и много", то есть такая штука как ram drive...

Создаете из памяти, копируете туда "что надо", работаете.

Идея хранить в БД в одной ячейке текст - ущербна.

Но это несколько проще, чем хранить в файлах.

---------- Добавлено 23.12.2019 в 14:31 ----------

ЗЫ. Ощущение такое, что вы хотите какой-то "хайлоад" сделать без опыта вообще и без понимания как работают простейшие вещи.

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

В первом случае вам "как надо" скажет тот, кого наймете. Во втором случае делайте в файлах и не морочьте людям голову.