|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Serge Sapozhnikov 2:4635/4.34 16 May 2002 15:54:25 To : Vova Aksionov Subject : id ? -------------------------------------------------------------------------------- 16 May 02 10:23, you wrote to me: >> Hа практике почему-то char-поле использовать удобнее - нет >> ограничения на длину (объявил домен как varchar(128) - и хранится >> компактно и не нужно ограничивать себя идиотскими диапазонами). Да >> еще можно и естественные названия VA> Hи фига себе - компактно! Я имел ввиду в сравнении с char. А ты что подумал? VA> один байт как byte способен хранить 256 кодов а один как символ - VA> выкинь более половины и получишь плохочитаемую фигню. А если только VA> цифры то вообще 10 значений. Т.е. кодировать строкой неэффективнее от VA> 2 до 25 раз. Причем это очень грубая прикидка. А по полю еще индекс VA> как правило есть - умножает на 2 и т.п. Hу давай прикинем если конкретики охота: пусть на кодирование филиала уходит от 4 до 8 символов, на кодирование целочисленного ID (рассматриваем суррогатный ключ) в строковом виде от 1 до 10 (unsigned int 32 bit). В среднем 6 + 8 (это 99999999 ключей) + 1 (точка в случае двухуровневой иерархии) = примерно 15 байт на ключ. Пусть 16. В 4 раза больше чем int (как правило 32 bit). Большинство серверов хранит varchar компактно, сколько реально занимает entry, столько на диске и выделяется (Interbase, Oracle, Informix, Sybase). С индексами не так однозначно. В случае Interbase данные буду сжаты, а строковые данные сжимаются ну очень хорошо. В случае Informix index entry для varchar-поля будет занимать макс. длину, то есть 128 для varchar(128). Действительно плохо. Для Informix меняем домен на varchar(16) :-) Для других серверов не знаю как индексы хранятся. Кто в курсе - делитесь. Итак, если ключ текстовый и занимает 16 символов (это, кста, очень большой запас, так как суррогатные ключики обычно делают на autoinc int, то есть начинаться будут с 1, потом 10, потом 100, а дополнять их нулями слева мы ессно не будем:-) , то в лучшем случае получаем в 4 раза больше. В худшем зависит от способа хранения индексов. Данные по Informix известны, можно прикинуть для него. Если varchar(16) то получаем лучший случай и общая разница 4 раза, если же varchar(128) то нужно считать общее число FK (индексы по FK будут составлять основной объем), но примерно видится более чем в 10 раз, но меньше чем 100 :-) Hу а реально, пусть индексы на int занимают 300MB. Что, 3-4GB это много? Чихать я _нынче_ хотел на такой объем, если скорость некритична. Good luck, Serge --- [frogbot@ukr.net] [ICQ #11038130] * Origin: DM4 (2:4635/4.34) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/27863ce3e1b9.html, оценка из 5, голосов 10
|