alex bw
Member
Откуда:
Сообщений: 10
|
| Nick Anikin | 1) а что за дуратские текстовые ID длиной 7 байт? используйте числовые ID
если есть необходимость хранить длинные логины пользователей, заведите отдельную таблицу:
USERID:USERLOGIN, где USERID типа INT (4 байта), а USERLOGIN - текстовое поле длиной хоть 7, хоть 207 символов, и работайте в остальных таблицах и в веб-приложении с USERID
аналогично и TEXTID, если текстов меньше 65 тысяч, то для их id можно использовать и SMALLINT (2 байта)
для таблицы с "матрицей" получите экономию места почти в 2 раза
|
да, конечно так. я просто не обратил внимание при описании на это. конечно используется нормальный формат.
|
2) размер индексов вы считаете неправильно
для MyISAM таблиц максимальный размер индекса считается по формуле:
(длина ключа + 4) / 0.67 * кол-во записей
т.е. размер индекса по полю в 4 байта для 4 млрд записей будет примерно 50 гб (это конечно в худшем случае)
http://dev.mysql.com/doc/refman/5.0/en/key-space.html
3) | alex bw | | Я просто не знаю насколько быстр мускул будет в интенсивной работе с запросами, где каждый ответ достигает 20кил. |
запрос типа SELECT USER_DETAIL FROM users WHERE ID=1 будет отрабатывать практически моментально, 20 кб - это мало :)
|
за это отдельное спасибо!
|
4) все зависи от того, какие запросы будут делаться к базеи как часто...
что происходит при генерации страницы? когда происходят update'ы таблиц? опишите подробнее
например, если нужно выбрать сразу свойства всех текстов для одного пользователя, вариант с хранением свойств в одном текстовом поле на мой взгляд хорош (вам не нужен индекс по id текстов, не нужно выбирать конкретный текст и свойства, нужно выбрать сразу все свойства для данного пользователя - запрос SELECT USER_DETAIL FROM users WHERE ID=1 отработает очень быстро, дальше обработаете строку как надо)
если же нужно часто обновлять/добавлять эти свойства, этот способ плох
допустим, у вас часто будет выполняться запрос на изменение даже одного свойства у одного текста, но для всех пользователей: придется выбирать 200 тыс записей по 20 килобайт, изменять в них один байт и снова записывать в таблицу!
при добавлении одного текста вам поять же придется увеличить на 1 байт каждую запись из 200 тысяч, подозреваю, что это будет происходить ОЧЕНЬ долго
выбор структуры таблиц зависит от запросов, которые нужно выполнять
|
Есть два типа веб-страниц, где типичные запросы такие
1) селект к обоим таблицам. без апдейтов
2) селект из второй таблицы и апдейт ее же.
Именно SELECT USER_DETAIL FROM users WHERE ID=1 и будет присутствовать в обоих вариантах.
Апдейт второй таблицы происходит для конкретного пользователя, но не для всех одновременно.
Возможна ситуация, при которой при количестве текстов 10.000, у одного пользователя может храниться USER_DETAIL размером 8564, а у другого 9688, и у третьего 10.000
Все зависит от того, с каким поселдним текстом имел дело юзер. обновление происходит для конкретного пользователя по мере необходимости. И ни в коем случае не для всех одновременно.
Так как по сути эти свойства не самих текстов, а отношения конкретного пользователя с конкретным текстом.
|
P.S.
А для чего вообще это нужно? Хранить соответствия между ВСЕМИ пользователями и ВСЕМИ текстами? Может быть, стоит начать с продумывания того, как уменьшить количество этих соответствий? |
У меня сейчас и стоит выбор между 3 и 13 состояниями текста для конкретного пользователя, но это не принципиально.
А пример для трех состояний может быть таков:
User=1 и Text=1, состояния такие как "непрочтен/не прочтен", "занесен в фавориты"
Тогда в случае простого текстового обозначения состояния можно использовать такие варианты как:
0= непрочтен
1= прочтен
2= прочтен и занесен в фавориты
В случае с побитным отображением, для типа blob:
один байт может содержать информацию о 4 текстах, где пара битов:
00= непрочтен
10= прочтен
11= прочтен и занесен в фавориты
| автор | Что касается выбора BLOB/TEXT - думайте сами, что вам нужно. Вы все правильно написали: TEXT - будет больше занимать, но меньше расчетов в программе, BLOB - наоборот. Если критично место на диске, делайте через BLOB.
И еще я не понял, что значит 13 свойств. У комбинации USERID-TEXTID может быть только одно свойство из 13ти и вам нужно указать какое именно? Или каждое из 13ти свойств - это логическая переменная есть/нет (т.е. связка USERID-TEXTID может обладать например свойствами 1,3,7 и не обладать остальными)? Если последнее, то ваши расчеты не верны, для хранения 13 свойств нужно будет 13 бит минимум, а не 4.
|
А для 13 состояний побитно несколько сложнее, но тоже реализуемо четырьмя битами (максимум 16 состояний)
Можно ведь добавить состояние, не равное "да/нет", а например 5-балл.оценку
Тогда получаем такие 13 вариантов:
0000= непрочтен
1000= прочтен
1001= прочтен, оценка "1"
1100= прочтен и занесен в фавориты
1101= прочтен и занесен в фавориты, оценка "1"
...
я уже придумал таблицу соответствий |
blob vs text (для больших размеров данных) [new]
Re: blob vs text (для больших размеров данных) [new]