Стандартная ситуация: необходимо внедрить на сайте небольшой магазинчик. Товар представленный в карточках по мимо названия и описания имеет теги и категорию. При таком раскладе у получается 4 таблицы в бд (товары, категории, привязка тегов, теги) ещё когда начинал изучать php я не парился и просто добавлял их в сам код в массив а не в бд. По итогу результат одинаковый, а скорость выше из за того что вся информация хранится "локально", однако как я погляжу для этих целей всегда используется бд и такой подход считается на порядок профессиональнее. Однако в чём практичность?
Но ведь для этих целей можно создать интерфейс. А создать его для массива намного проще чем для бд, который и так должен быть
А, хе-хе) Верно. Вот и прозрение --- Добавлено --- Хотя стоп. Откат прозрения. Ну допустим так, в json файле, что от этого теряется?
В организации доступа к тем или иным данным в массиве. БД тоже своего рода массив. Где каждая ячейка может(не обязательно) быть проиндексирована. Для практически мгновенного доступа к ней. Примерно как к элементу массива по ключу. Например $array['key']. Кроме того, эти данные постоянно содержатся в оперативной памяти, а массив туда нужно еще поместить. Отсюда вывод. Если у вас данных не очень много, то хранить вы их можете хоть в массиве, хоть в тексте, хоть в JSON CSV и тд. Особенно, если правильно их организуете. Скорость и удобство доступа к данным будут даже выше, чем у БД. Но при увеличении количества записей, и особенно активности пользователей, вы начнете сталкиваться с, всё более сложными проблемами.
Знаем, видали. Гонять все на фронт при каждом чихе. Тогда уже раз на клиент все выгрузите и там на JS разруливайте. Тут и пых не нужен Шо только люди не выдумывают, чтобы не использовать годные инструменты.
БД умные люди уже спроектировали, и приложили все усилия, чтоб обеспечить конкурентный доступ к одним и тем же данным. Чтоб несколько пользователей могли добавлять данные в одни таблицы. Плюс SQL - шикарный инструмент для выборок, позволяющий писать один запрос вместо 100 строк кода на пыхе. И т.п. Пока у тебя 4 товара, условно, заказы не хранятся вообще, аналитических задач не стоит, и т.п. - да, в json-е может быть даже удобнее и быстрее. А вот если надо регать пользователей, хранить/менять статус заказов, ну в общем маломальская логика корзины, работы с заказами - начнутся проблемы.
Хотя без подготовки лучше не лезть. Будет только хуже. Так что загоняйте ваши 4 товара в json-файл и не рыпайтесь
Спасибо за хорошие ответы. --- Добавлено --- Мы такие умные шо я не можу. Вопрос про структуру данных, тема которая сама по себе тема требующая анализа. Тут же старожил просто заходит в ветку "php для новичков" и 70% его ответов насмешка над тем кого он считает слабым разработчиком. Друг, я создал этот вопрос не потому что не умею/лень переходить от прежнего способа хранения данных, а потому что уже все сделал и задал себе вопрос "чем оправдана такая потеря скорости во благо профессионального подхода" и хотел услышать мнение других людей.
Друг, никакой потери скорости нет или она минимальна ради улучшения функционала. Вы подобные вопросы можете задавать, только когда у вас 4 товара. Потом уже такие вопросы не возникают (если вы не мазохист). «Крест» с линией профессионального подхода возникает уже на «пятом» товаре --- Добавлено --- Профи тоже могут оптимизировать путем сохранения «промежуточных результатов» в файлах и т.п. Но никому в голову не приходит отказываться от БД.