P
closure table и позволяет в теории обходится без алиаслистинга
Size: a a a
2020 September 24
S
Я не защищаю это решение, не смотря на то что я его впиливал, так как я его не тестировал на больших данных. И не могу быть уверенным на 100% в его правильности
S
closure table и позволяет в теории обходится без алиаслистинга
Теоретически да и даже можно переписать что-то типа getParentIds на его и в целом грохнуть aliaslisting
S
Но на этом листинге много чего завязано
AS
Вопрос в том, чтобы оно опять не стало узким местом
S
Нужно нагенерить большую таблицу и проверить
S
На сайте с 60к ресурсов не упало
S
И в целом ничего не сломало
P
главные недостатки - чем больше вложенность, тем больше записей в таблице связей и сложности с перемещением ветвей дерева
AS
Ну вот у меня сейчас 600к товаров, под 90к папок и 5.5 млн отзывов (в отдельной таблице). С пустым siteCache.idx работает, а создать его не может
AS
aliasListing только для папок, естественно
P
ну вот ты мог и товары в отдельной таблице хранить
P
тогда и папок стало бы сильно меньше
S
Ну вот у меня сейчас 600к товаров, под 90к папок и 5.5 млн отзывов (в отдельной таблице). С пустым siteCache.idx работает, а создать его не может
21век?
AS
Так я мож и на ларе делать, но мы же все на эво, потому что любим дерево ))
P
так в твоем случае дерево не нужно
P
потому что никто не будет даже его открывать
AS
21век?
Да обычный сео-клон сайтов с отзывами, просто они выросли больше ожидаемого)
AS
Дерево отлично открывается
AS
3к категорий в папке каталог, в категорях эти 80к брендов (по среднему 30-40 штук в ветке), в этих 80 к брендов 600 к товаров (тоже по 10-20 в ветке)