Miracle

Рейтинг
376
Регистрация
20.08.2004

Спасибо. Почитаю. Ооднако никогда с такими типами не работал, не знаю на сколько они хороши.

Кстати, а как при обычной выборке получить данные и с ними работать?

netwind:
это плохой выбор индексов с точки зрения экономии места

да. таблица увеличилась почти в двое

netwind:
и скорости обновлений таблицы

потому собственно и спрашивал

netwind:
В индексах хранится каждое значение 0 или 1 для каждой записи.

это логично, но не понятно к чему вы это сказали, есть альтернатива?

netwind:
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.

пожалуйста, уточните что надо сделать, я ничего не понял.

netwind:
Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.

в самом начале об этом и спрашивал.

netwind:
И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?

простите. дальше не понял, хранятся в mysql

вот таблица

CREATE TABLE `table_gr` (
`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 тыс., но я же о будущем думаю :)

[umka:
]И вообще, напишите лучше конкретные примеры, а то я лично смутно понимаю, какие у вас таблицы и что вы от них хотите )

а что конкретней написать.

вроде написал

текущая аблица с полями

gr_table {gr_id, otherfields...., prop), prop1 ....

первый вариант дополнительная таблица new_table { gr_id, prop1, ....

второй вариант с доп полями gr_table {gr_id, otherfields...., prop, prop1 ....

не знаю, мне кажется оригинал таблицы вас только сбивал., я же все упростил

А это так важно?

Раньше вывод был возможен от 10000 без процентов, те просто 50 баксов. Не знаю как сейчас.

Это не ново, другое дело налоговая может придолбаться.

по моим наблюдениям разницы нет.

важен качественный контент.

делал по всякому у каждого из способов есть свои плюсы и свои минусы. вариантов, кстати, формирования урл, много, и не ограничивается тем что вы предложили.

я бы , на самом деле вообще сделал так

....орум.рф/дерматит-кожный_дерматит.htm

или так ....орум.рф/кожный_дерматит.htm

если это делается для пользователя то ему ваши каталоги до одного места, он в урл в 99.99% менять их не будет.

для поисковиков до попы.

вот единственное что для статистики хождения по каталогам...

повторюсь, на каждом своем новом проекте пробовал по разному и нет идеального способа :)

spermint:
А вот как новые ключи генерировать, кто подскажет?

инструменты-параметры программы-безопастность-сменить ключи

Всего: 3947