Что логичней будет, сериализация или в новой таблице?
Есть например категории для объявлений.
Где их лучше хранить? В отдельной таблице, или в таблице с объявлениями, но сериализовать? В Битриксе например все такие свойства сериализуется.
Ссылку почитал, но в данном случаи не понятно. С одной стороны лишних запросов не будет если сериализовать но очень не удобно работать. С другой стороны удобство но лишние проверки и запросы.
chelkaz: ссылку поменял, более наглядно. Лишние запросы в вашем случае отнимут пару сотых секунды. А "очень неудобно" - это мягко сказано. Этот код просто будет неподдерживаем. Плюс зависим от количества объявлений в базе. Плюс вам придется изобретать собственный аналог уже существующих решений (ссылка на baum тут уже мелькнула). Когда объявлений десять и самих категорий 5 - поменять категории не так сложно, а когда объявлений станет 50 тысяч, а категорий сотня и они куда глубже 1 уровня (может не при вас, а при человеке, который будет поддерживать проект после вас)? Плюс если вы не будете хранить категории отдельной таблицей, вы столкнетесь с такими проблемами: необходимо перед обновлением категории лочить все объявления, принадлежащие ей, если кто-то из пользователей создавал в такой категории объявление или редактировал. после изменений в категории вам нужно будет оповестить его об изменениях. Самое интересное - как вы собираетесь следить за тем, чтобы пользователи не создавали собственные выдуманные категории? С внешней таблицей понятно, вы даете ему список существующих ключей. С массивами же вам придется при создании объявления для валидации имени категории сканировать всю базу объявлений и строить виртуальное дерево каждый раз, Каждый, Карл! 50 объявлений? Не проблема, 50 тысяч? ну уже посложнее и ждать подольше (при каждом создании объявления), 500 тысяч? Шеф, нам надо больше памяти покупать.
chelkaz: Ну и если на то пошло, почитайте про принципы Solid. Смешение категорий и объявлений в вашем случае его неплохо так нарушает. да и нормализация базы данных страдает.
в отдельной таблице это легче поддерживать
Таблица категорий
advert_category
id mpath parent_id name
*** Я предпочитаю хранить вложенность категорий/коменты в виде Materialized Path + родитель потомок
Нужно объявление хранить в нескольких категориях создаем таблицу ( это правило работает ко всем что нужно хранить многое к одному или ко многим - промежуточная таблица via pivot итд )
advert_category_pivot
id advert_id category_id
PS не используйте сериализацию данных поиск по таким данным делать очень сложно и это будет без индексов работать.
Если уж нужно сохранить массив в БД то только JSON mysql 5.6 или 5.7 умеет работать и индексировать json. Но в новых версиях есть регрессия с производительностью
Да и завязывайте с битриксом, мы плохого не советуем)
Если по данным нужны выборки и/или поиск, то их не стоит хранить в сериализованном виде.
Сериализация может подойти, когда данные типа объект или массив нужно только хранить и выводить.
Простой
