Модель на двух таблицах

[fly2k]

Ку!

Начитался я тут про разницу в использовании char и varchar(mysql). Якобы если запись в таблице статического размера, то можно выиграть до 20% в скорости запросов.
Если заморачиваться на эту тему, то нада делать две таблицы, наприме: model и model_data, в первой все поля фиксированного размера(char), во второй - всё остальное(varchar).

Так вот, как грамотнее это реализовать в Yii? Я вижу несколько вариантов:

1) Делать таки две модели model и model_data и связывать их 1к1 через relations. Тогда не очень понятно как быть с формами редактирования и тд? Ведь для юзера в одной форме должны быть поля из обеих таблиц.

2) Делать одну модель, переопределять ее внутренности касательно работы с данными(писать/читать сразу из двух таблиц вместо одной). Тут подозреваю что переопределением CRUD дело не ограничится. Что еще нада предусмотреть?

3) Забыть про char как страшный сон и наслаждаться varchar'ом

Спасибо!

[rak]

если данные фиксированной длины(аля md5), то char
если переменной, то varchar
к чему тут разделение на 2 таблицы, не пойму...

[fly2k]

К тому, что когда записей ооочень много, и запросы по ним не отличаются тривиальностью, то занимать они начинают много времени

Так, вот про мускул пишут, что если ROW_FORMAT=FIXED, то скорость выполнения запросов увеличивается на 20%, как бы потому что все записи одинакового размера и мускул шустрее их пережевывает. Насколько я понял, это касается только MyISAM. Сам я этого не проверял, не тестил, и вообще особо в подробности не вдавался. Так что если кто знающий скажет, что мол овчинка выделки не стоит, то может и успокоюсь Но попробовать хочется.

Так вот, мои тяжелые запросы используют как раз таки только те данные которые имеют фиксированный размер для хранения(айди, счетчики, в общем - числа). Но модель сама по себе не ограничивается циферками, там предполагается и куча текстовых полей с неопределенной длиной, типа описания, урлов и тд... Но в тяжелых запросах эти данные не нужны.

Вот и напрашивается решение - разбить таблицу на две: одна с минимальным набором полей необходимым для тяжелых запросов, а вторая - все остальное.

Блин, могет я чего не так объясняю?

[rak]

если нужен определенный набор полей, то их и нужно выбирать(т.е. вместо select * )

Код: Выделить всё

select field1, field2 from ...
 

join тут только усугубит ситуацию
зы. про myisam без fk и транзакций в большинстве случаев лучше вообще забыть

[fly2k]

Ну понятно что не "select * from..."
Но, суть фишки про ускорение на 20% не в том что выбирать нада только поля с фиксированным размером, а именно в том, чтобы сама структура таблицы была с фиксированным размером записи. То есть если в таблице есть хоть одно поле varchar, то уже всё - не канает... и пофигу что я не буду это поле в запросе использовать. Нада чтобы ВСЕ поля в таблице были фиксированного размера, только в этом случае обещают прирост в 20% по скорости.

Без джойнов никак - там как раз минимум 3-4 таблицы получится в джойне. Запросы тяжелые только по чтению. Внесение изменений позволяется откладывать, группируя в пачки, так что тут вполне хватить обычных локов. Транзакции в этом смысле не нужны. К тому же, тоже вычитал, что если основная нагрузка идет по select'ам то myisam гораздо быстрее чем innodb. В этом я уже и сам убедился, когда пробовал ФИАС базу юзать из myisam и innodb. Вторая по обычным выборкам с where like 'some%' просто поразила своей тормознутостью

ЗЫ. Чтобы было понятнее, эти мои тяжелые запросы к Yii отношения не имеют, они будут запускаться по крону или еще как...

[yiijeka]

А ещё везде где можно enum, с varchar вы всё верно говорите.

[fly2k]

Про enum можно подробнее? А именно, какие преимущества в использовании enum вместо tiny int unsigned(тоже один байт)? Просто не хотелось бы иногда ограничивать себя списком значений, когда можно использовать один байт и иметь 256 значений прозапас. Например, есть у меня поля определенного статуса, изначально статусов всего 3(можно и enum), но вероятно в дальнейшем понадобится расширить этот список. Можно и базу будет поменять, но не хотелось бы без серьезного повода это делать... А tiny int - с запасом хватит...

Ну и по субжу так и не понятно как лучше делать

[yiijeka]

tiny int - принимает только int, а enum - "любое" значение(текст....), но при этом хранит только числовые индексы.

Про enum можно чуточку прочитать тут http://www.askdev.ru/mysql/6701/varchar-vs-enum/
Про оптимизацию и фичи mysql очень хорошая книга - http://www.amazon.com/High-Performance- ... 1449314287

[rak]

вообще, если уж на то пошло, то enum стоит использовать только там, где точно знаешь, что набор значений не изменится, т.к. добавление нового значения - это alter table

[fly2k]

спасибо за линки, почитаю

...а по субжу тишина

[fly2k]

Вот: http://www.yiiframework.com/wiki/19/how ... re-models/ - для моей задачи оно самое.

И вообще понравилось: http://www.yiiframework.com/doc/guide/1 ... rm.builder
Вот это трувэй

D общем буду делать вариант 1 - две модели с общими вьюками и контроллером(?) чтобы для юзера это было как одна модель... зато вся ДБ кухня в Yii с этими моделями будет работать без костылей.

ЗЫ Это ведь я прально думаю(еще не начал делать - начитался, каша не устаканилась еще) что контроллера одного хватит?