а. не правильней ли сделать доп таблицу сразу на все prop?
gr_id prop_1 prop_2 ... prop_Х (почему то мне кажется что это все же запрос по проще, хоть и места будет больше занимать)
б. value 1 и 0 мне кажется лишние, просто есть есть, тогда 1 если нет тогда нет, просто удалять свойство.
Но самое важное, почему вы решили предложить именно такой способ. Меня интересую плюсы :). Экономия места? Это несомненно плюс, но в тоже время 1 лишний запрос а это еще больших минус. А так как у меня в основном СЕЛЕКТЫ и причем их много, то теперь в место одного надо будет делать их два!
netwind: это плохой выбор индексов с точки зрения экономии места
да. таблица увеличилась почти в двое
netwind: и скорости обновлений таблицы
потому собственно и спрашивал
netwind: В индексах хранится каждое значение 0 или 1 для каждой записи.
это логично, но не понятно к чему вы это сказали, есть альтернатива?
netwind: так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
пожалуйста, уточните что надо сделать, я ничего не понял.
netwind: Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.
в самом начале об этом и спрашивал.
netwind: И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?
не вяжется как то ваш комплетк с вашей аватарой :)
начните диктовать свои условия.
А для вас это волшебный пендель что бы не засиживаться на одном месте а развиваться дальше.
С Днем Варенья!
всю тему не читал. идея хорошая но бессмысленная.
поставить сателит за пару баксов и все ...
я понял. но, не совсем понятны две вещи.
а. не правильней ли сделать доп таблицу сразу на все prop?
gr_id prop_1 prop_2 ... prop_Х (почему то мне кажется что это все же запрос по проще, хоть и места будет больше занимать)
б. value 1 и 0 мне кажется лишние, просто есть есть, тогда 1 если нет тогда нет, просто удалять свойство.
Но самое важное, почему вы решили предложить именно такой способ. Меня интересую плюсы :). Экономия места? Это несомненно плюс, но в тоже время 1 лишний запрос а это еще больших минус. А так как у меня в основном СЕЛЕКТЫ и причем их много, то теперь в место одного надо будет делать их два!
а. для селекта что бы получить свойства
б. для сортировки, может быть как по одному так и по всем сразу
Спасибо. Почитаю. Ооднако никогда с такими типами не работал, не знаю на сколько они хороши.
Кстати, а как при обычной выборке получить данные и с ними работать?
это плохой выбор индексов с точки зрения экономии места
да. таблица увеличилась почти в двое
и скорости обновлений таблицы
потому собственно и спрашивал
В индексах хранится каждое значение 0 или 1 для каждой записи.
это логично, но не понятно к чему вы это сказали, есть альтернатива?
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
пожалуйста, уточните что надо сделать, я ничего не понял.
Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.
в самом начале об этом и спрашивал.
И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?
простите. дальше не понял, хранятся в mysql
вот таблица
`gr_id` int(11) unsigned NOT NULL auto_increment,
`user_id` int(11) unsigned NOT NULL default '0',
`gr_1day` date default NULL,
`gr_a_days` tinyint(3) unsigned default '31',
`gr_b_days` tinyint(3) unsigned default '3',
`gr_text` text,
`gr_last_use` int(11) default NULL,
`gr_activity` tinyint(1) default '1',
`gr_x_day` tinyint(3) unsigned default NULL,
`gr_points_qty` smallint(6) default '0',
`gr_field_value_qty` smallint(6) default '0',
`gr_prop` tinyint(1) default '0',
`gr_prop1` tinyint(1) default '0',
`gr_prop2` tinyint(1) default '0',
`gr_prop3` tinyint(1) default '0',
`gr_prop4` tinyint(1) default '0',
`gr_prop5` tinyint(1) default '0',
`gr_prop6` tinyint(1) default '0',
`gr_prop7` tinyint(1) default '0',
PRIMARY KEY (`gr_id`),
KEY `bt_FKIndex1` (`user_id`),
KEY `user_id` (`user_id`),
KEY `gr_activity` (`gr_activity`),
KEY `gr_prop` (`gr_prop`),
KEY `gr_prop1` (`gr_prop1`),
KEY `gr_prop2` (`gr_prop2`),
KEY `gr_prop3` (`gr_prop3`),
KEY `gr_prop4` (`gr_prop4`),
KEY `gr_prop5` (`gr_prop5`),
KEY `gr_prop6` (`gr_prop6`),
KEY `gr_prop7` (`gr_prop7`)
)
я смотрю в будущее, и могу сказать что кол-во графиков увеличивается
сейчас , не много 120000 тыс., но я же о будущем думаю :)
]И вообще, напишите лучше конкретные примеры, а то я лично смутно понимаю, какие у вас таблицы и что вы от них хотите )
а что конкретней написать.
вроде написал
текущая аблица с полями
gr_table {gr_id, otherfields...., prop), prop1 ....
первый вариант дополнительная таблица new_table { gr_id, prop1, ....
второй вариант с доп полями gr_table {gr_id, otherfields...., prop, prop1 ....
не знаю, мне кажется оригинал таблицы вас только сбивал., я же все упростил