Что логичней будет, сериализация или в новой таблице?

Question

[chelkaz]

Есть например категории для объявлений.
Где их лучше хранить? В отдельной таблице, или в таблице с объявлениями, но сериализовать? В Битриксе например все такие свойства сериализуется.

Answer 1

[65536]

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

кто удалит мой ответ - будет заживо сварен в битриксе

Comments

[netyshka]

а ты забавный:)

Answer 2

[Дмитрий Евграфович]

В новой. Битрикс вообще не эталон. Еще чтобы вас смутить ссылку оставлю www.getinfo.ru/article610.html

Comments

[Дмитрий Евграфович]

Что-то поторопился со ссылкой, там тема деревьев практически не освещена. Прогуглите nested sets, вам понравится.

[chelkaz]

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

[Дмитрий Евграфович]

chelkaz: ссылку поменял, более наглядно. Лишние запросы в вашем случае отнимут пару сотых секунды. А "очень неудобно" - это мягко сказано. Этот код просто будет неподдерживаем. Плюс зависим от количества объявлений в базе. Плюс вам придется изобретать собственный аналог уже существующих решений (ссылка на baum тут уже мелькнула). Когда объявлений десять и самих категорий 5 - поменять категории не так сложно, а когда объявлений станет 50 тысяч, а категорий сотня и они куда глубже 1 уровня (может не при вас, а при человеке, который будет поддерживать проект после вас)? Плюс если вы не будете хранить категории отдельной таблицей, вы столкнетесь с такими проблемами: необходимо перед обновлением категории лочить все объявления, принадлежащие ей, если кто-то из пользователей создавал в такой категории объявление или редактировал. после изменений в категории вам нужно будет оповестить его об изменениях. Самое интересное - как вы собираетесь следить за тем, чтобы пользователи не создавали собственные выдуманные категории? С внешней таблицей понятно, вы даете ему список существующих ключей. С массивами же вам придется при создании объявления для валидации имени категории сканировать всю базу объявлений и строить виртуальное дерево каждый раз, Каждый, Карл! 50 объявлений? Не проблема, 50 тысяч? ну уже посложнее и ждать подольше (при каждом создании объявления), 500 тысяч? Шеф, нам надо больше памяти покупать.

[Дмитрий Евграфович]

chelkaz: Ну и если на то пошло, почитайте про принципы Solid. Смешение категорий и объявлений в вашем случае его неплохо так нарушает. да и нормализация базы данных страдает.

Answer 3

[Александр N++]

в отдельной таблице это легче поддерживать
Таблица категорий
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. Но в новых версиях есть регрессия с производительностью

Да и завязывайте с битриксом, мы плохого не советуем)

Answer 4

[Silm]

Если по данным нужны выборки и/или поиск, то их не стоит хранить в сериализованном виде.
Сериализация может подойти, когда данные типа объект или массив нужно только хранить и выводить.