Дело в том, что у вас может быть для всей базы установлена кодировка utf8, а для какого-нибудь отдельного поля в какой-то таблице установлена кодировка cp1251.
Вячеслав Успенский, в utf8 русские буквы занимают 2 байта, а ASCII-символы -- 1 байт. Поэтому первые 3 поля весят по 32 байта, а вот 4-е поле может весить и все 128 байт, в зависимости от кол-ва русских букв.
Скиньте проблемный запрс.
К А, а эта сотня объектов собраны в какую-то структуру или просто разбросаны по коду (никогда так не делайте)? Если вы или кто-то насоздавал сотню переменных, то только ручками или через список всех переменных.
Вячеслав Успенский, а теперь прикиньте, если бы вы 16-байтные идентификаторы хранили не в CHAR(32), который занимает 32 байта, а в BINARY(16), то смогли бы сэкономить по 3*16=48 байт на каждой записи. Плюс экономия на размере индекса. Косвенным бонусом будет более высокая скорость отработки запросов. Это замечание общего характера. Что касается, сути мне не понятна ваша проблема. Запрос долго отрабатывает или что?
Пересечение моих книг и ваших очень даже не пусто =)
А именно: мой любимый Зорич, 2 тома Ширяева, Комбинаторика Виленкина (решил из него ВСЕ задачи), и Александров ("кирпич"). Вот только что-то Демидовича не вижу...
semki096, так как вам в последствии потребуется быстро строить графики, то вам нужно быстрое чтение временных рядов. Для быстрого чтения временных рядов используются колоночные СУБД или подсистемы хранения колоночного типа (например, в PostgreSQL).
