DE
Потянет, но это не копейки и просто совет
Size: a a a
2021 September 11
DE
Там многое поменялось
G
Без проблем потянет
G
Сложности бывают, когда таблица за 100гб уезжает
2021 September 12
DE
Когда таблица 55Гб и содержит 107 обязательных полей вообще супер ситуация ))
DE
Недавно в такой бывал )))
DE
Переехал с ней на пг. Добавил индексы, чтобы хоть как-то работало. Так падла до 100Гб раздулась. Недели две я её ковырял и нормализовал на 6-7 таблиц. Прекол в том, что это таблица за один год. И вот сейчас надо к тем нормализованным данным подлить данные из похожей таблицы за другой год. А я там везде CREATE TABLE AS юзал. Короче теперь нужно заново запросы писать проверяя на имеющиеся записи.
DE
Мускул бы крякнул мне кажется. Там пг то с трудом некоторые запросы обрабатывает
DE
После нормализации выборки конечно моментально делаются
V
День добрый. В интернет магазине необходимо работать с товарами у которых разный набор параметров. Вариант который напрашивается сам собой это схема EAV для БД, но как везде и пишут её надо уметь готовить, плюс всегда есть вероятность отгрести проблемы в дальнейшем с производительностью, а тем более со сложными выборками. Учитывая нативную поддержку JSON в MySQL не будет ли выходом использовать его вместо EAV ?
DE
Нет, нужны типы товаров и композитные модели. Вопрос решаемый и интересный
DE
У каждого типа свой набор свойств, но есть ещё и общие для всех товаров свойства
DE
Таблица с общими свойствами и по таблице для каждого типа
DE
DE
DE
Внимательно смотри
DE
https://gitlab.com/pyro-plus/catalog-module/-/tree/master/src
Вот имплементация аналогичного решения на пыхе
Вот имплементация аналогичного решения на пыхе
DE
Product и ProductType